-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Optimize planning for projected nested union #18713
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
base: main
Are you sure you want to change the base?
Conversation
|
🤖 |
|
I'll run the sql_planner_extended benchmark against this branch as that is the one that to me most reflects whether #17261 should be closed. I'm hopeful :) |
I have my vm in gc working on it too |
|
🤖: Benchmark completed Details
|
1.23.- 2.5x better certainly seems much better 🎉 ! Though I am not sure if we have fixed the exponential planning time |
|
Given the time estimate on my machine for the extended planner test I'm going to assume it's not impacting that benchmark as much as I'd like to see: |
|
I guess this won't be enough to close the issue but I will take any small wins for now. |
|
Which issue does this PR close?
Rationale for this change
as explained in #17261 (comment) and discussion in the above mentioned issue
What changes are included in this PR?
Projected Nested Union are now merged with their parent union.
Are these changes tested?
Tested it by Github CI. Works for the scenario discussed in the above mentioned issue.
Are there any user-facing changes?
Yes? logical plans for some queries should be different(and better) now. No syntax changes.