[Minor] Short circuit ApplyFunctionRewrites
if there are no function rewrites
#11765
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Which issue does this PR close?
Relates to #9373 and #9375.
Rationale for this change
I'm dealing with a situation where we have deeply nested plans, which we want to execute and stream the data into storage (Parquet/Delta), and we're hitting the stack overflow problem observed in the aforementioned issues.
Since this is on a write path we don't really need the analyzer/optimizer rules (I think), which are a part of the problem due to tree node recursion that takes place there. This is not an issue, since those can easily be opted out of via
with_analyzer_rules
/with_optimizer_rules
.However, the tightest bottleneck as per lldb is actually
ApplyFunctionRewrites
, which can't be opted out of, even though after #11155 it has no rewrite rules by default.What changes are included in this PR?
Make
ApplyFunctionRewrites
simply bail out of the plan transformation/rewrite if it has no rules to apply (the default case presently).Are these changes tested?
I wanted to add a test that checks for reference equity of the in/out plans but then recalled
AnalyzerRule::analyze
takes ownership of it.So the only test is that I see a higher stack overflow threshold with this change.
Are there any user-facing changes?
None.