You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
depending on ?'s actual value, we may have indexed or sequential scan. Say we want to cache the plan by PREPARE command, question is (1) how many plans we want to cache? (2) how to fast and accurately decide which plan to use when ? is given?
Classic wisdom is that first optimization then exec following plan. The problem is obvious because optimizer can be wrong. If executor can call optimizer during the middle of execution, then optimizer can get a chance to re-optimize and may generate better plan. The reopt could be small (swap hash join sides, etc) or big (total plan shape shuffle). Problems are: (1) when to invoke reopt? (2) will it cause unstable or even slower performance?
select * from a where i > ?
depending on ?'s actual value, we may have indexed or sequential scan. Say we want to cache the plan by PREPARE command, question is (1) how many plans we want to cache? (2) how to fast and accurately decide which plan to use when ? is given?
See https://www.postgresql.org/docs/current/sql-prepare.html for backgrounds.
Classic wisdom is that first optimization then exec following plan. The problem is obvious because optimizer can be wrong. If executor can call optimizer during the middle of execution, then optimizer can get a chance to re-optimize and may generate better plan. The reopt could be small (swap hash join sides, etc) or big (total plan shape shuffle). Problems are: (1) when to invoke reopt? (2) will it cause unstable or even slower performance?
See Spark's AQP.
The text was updated successfully, but these errors were encountered: