Skip to content

Are we really needed a smart statement timeout?

Andrey Lepikhov edited this page Apr 9, 2022 · 15 revisions

Intro

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.