-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Improve Planning Time #13015
Comments
I noticed this case has many aggregations (about 200). When planning an aggregation, the planner wraps a projection for it and creates the corresponding See the flamegraph, I highlight two parts:
I did a simple POC #13018 to avoid building the hash map and reduce the clone. The benchmark result like as below.
Most queries don't be affected but we can see the case
It reduces about 15% execution time. I think it could be a point that we can improve 🤔 I am still considering whether it is possible to avoid using |
Is your feature request related to a problem or challenge?
Follow on to #12950
@askalt added a benchmark for planning a benchmark with several aggregates. You can run it (with flamegraph) like
Some profiling
As can be seen from the flame graphs, a significant amount of the physical planning time is spent on creating ProjectionMapping. However, there are many other interesting places that can probably be made faster too
Describe the solution you'd like
It would be very nice to make this benchmark faster by optimizing these codepaths
Describe alternatives you've considered
Physical Planning could likely be made faster by optimizing EquivalenceProperty calculations. However, since it is a small part of the overall planning time maybe LogicalPlanning / SQLPlanning are better places to start
Additional context
No response
The text was updated successfully, but these errors were encountered: