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?
See Spark's AQP.
other issues
105 (research items there)
110
incrementally maintain stats (upon updates, when and how)
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.
105 (research items there)
110