Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[research] collection #196

Open
zhouqingqing opened this issue Aug 18, 2020 · 0 comments
Open

[research] collection #196

zhouqingqing opened this issue Aug 18, 2020 · 0 comments

Comments

@zhouqingqing
Copy link
Owner

zhouqingqing commented Aug 18, 2020

  1. parameter query
    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.

  1. query re-optimization

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.

  1. other issues
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant