Introduce OptimizerRule::rewrite to rewrite in place, rewrite ExprSimplifier (20% faster planning)#9954
Conversation
4f99bfc to
6be96c2
Compare
ExprSimplifier
168f63f to
dacbfa6
Compare
ExprSimplifierOptimizerRule::rewrite to rewrite in place, rewrite ExprSimplifier
dacbfa6 to
d95eca4
Compare
d95eca4 to
6d31211
Compare
OptimizerRule::rewrite to rewrite in place, rewrite ExprSimplifierOptimizerRule::rewrite to rewrite in place, rewrite ExprSimplifier (20% faster planning)
…lifyExprs` to avoid copies
c9ff49b to
e31a358
Compare
| simplifier.simplify(e) | ||
| }?; | ||
|
|
||
| plan.with_new_exprs(exprs, new_inputs) |
There was a problem hiding this comment.
The whole point of this PR is to remove the calls to expressions and new_with_exprs (which requires cloning all the expressions)
| }; | ||
|
|
||
| let exprs = plan | ||
| .expressions() |
There was a problem hiding this comment.
Calling expressions() clones all the expressions
|
@jackwener and @jayzhan211 here the next PR in the "don't copy so much in the optimizer" |
| /// If a rule use default None, it should traverse recursively plan inside itself | ||
| /// If returns `None`, the default, the rule must handle recursion itself | ||
| fn apply_order(&self) -> Option<ApplyOrder> { | ||
| None |
There was a problem hiding this comment.
I think most of the cases are BottomUp by default?
There was a problem hiding this comment.
I think most of the cases are BottomUp by default?
we can't assume it.
There was a problem hiding this comment.
I agree most of the cases probably should be bottom up (but not all). I'll keep an eye open for this as I work through the other optimizer rules
|
Thanks @jackwener and @jayzhan211 -- I assumed it would take some time to review these PRs but you are so efficient! I plan to spend a little time planning today to write down the remaining tasks (aka rewriting each OptimizerRule to use the new APIs) and then start cranking on them. CommonSubExprEliminate will be a tricky one but another major win I think |
…lifyExprs` to avoid copies (apache#9954)
Note: A substantial number of the changes in this PR are removing
&in tests. The actual logic change is quite smallWhich issue does this PR close?
Part of #9637
Rationale for this change
The less copying in the planner, the less time it takes to plan a query. Profiling from the
sql_plannerbenchmark in #9637 shows almost 25% of the time is spent inExprSimplifier, so let's make that faster.The current API of
OptimizerRules requires a copy of theLogicalPlanto be made. Thus we need a new API that allows for in place rewrites.What changes are included in this PR?
OptimizerRule::rewriteAPI for in place rewritesOptimizerto use the new APIExprSimplifierto implementrewriterather thantry_optimizeOpen questions:
OptimizerRuleAPI (I think so -- maybe we can do this as a follow on PR)Are these changes tested?
Yes by existing tests
Performance benchmark: 22% faster TPC-H planning, 26% faster TPC-DS planning
Details
Are there any user-facing changes?
Faster planning 🚀