-
Notifications
You must be signed in to change notification settings - Fork 55
Are we really needed a smart statement timeout?
If we make 'JOB' benchmark results with specific preferences (script):
max_parallel_workers_per_gather = 0
statement_timeout = 600000
we will see result on the graph below (gnuplot template, raw data):
As you can see, we have 22 queries, that can't be executed in reasonable time:
14a.sql, 14c.sql, 19a.sql, 19c.sql, 21a.sql, 21b.sql, 22a.sql, 22b.sql, 22c.sql, 22d.sql, 25a.sql, 25c.sql, 28b.sql, 29a.sql, 29b.sql, 29c.sql, 30c.sql, 31a.sql, 31b.sql, 31c.sql, 7a.sql, 7b.sql.
This Situation looks better with the parallel workers machinery usage, but for clarity we turned it off. What if we had a machinery to learn on a partial query plan, interrupted by a statement_timeout? We should have a chance to recognize situations, when we were interrupted under AQO control and have an option to make one more attempt with, possible, different query plan.