-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Apply filter early in TopK #16408
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
Apply filter early in TopK #16408
Conversation
Can you make a PR on our fork and we merge this into the main PR? |
Or you can just push to the main PR, I gave you write access to our fork :) My one question is: how does this optimization play with filter pushdown? If a child plan accepted the filter as Exact should we then not re-filter? A related question which you've alluded to before: if no child plan accepted the filter at all should we avoid updating it? |
I think avoiding running the filter twice for "exact cases" is optimal. Your second question: I think if we actually always use the filter for topk, I guess it isn't really wasteful. I think theoretically we should do it just before runing the topk instead of after (to avoid running it for the last iteration without using it). But also here I think it will be hard to show any benefit. |
I applied the changes to #15770 let's continue there |
Which issue does this PR close?
This depends on #15770
Rationale for this change
Perf changes (combined PRs - I'll rerun once #15770 is merged ):
What changes are included in this PR?
Are these changes tested?
Are there any user-facing changes?