-
Notifications
You must be signed in to change notification settings - Fork 28k
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
[SPARK-38959][SQL][FOLLOWUP] Do not optimize subqueries twice #38626
Conversation
// We can't run `OptimizeSubqueries` in this batch, as it will optimize the subqueries | ||
// twice which may break some optimizer rules that can only be applied once. The rule below | ||
// only invokes `OptimizeSubqueries` to optimize newly added subqueries. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm? This batch has only PartitionPruning
and RowLevelOperationRuntimeGroupFiltering
. What some optimizer rules are? PartitionPruning
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, you mean other Once batches in SparkOptimizer.defaultBatches
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But in Optimizer
where OptimizeSubqueries
also runs, there are also other Once batches but seems fine?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the optimizer batches are optimizing the same query plan. If OptimizeSubqueries
appears twice, it means the subqueries are optimized twice.
Note that, most optimizer rules don't optimize subqueries, they need OptimizeSubqueries
to invoke the entire optimizer to optimize subqueries recursively.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
inspired by #38619 , maybe we don't need to invoke the entire optimizer, but just a few rules to optimize this subquery.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the optimizer batches are optimizing the same query plan. If
OptimizeSubqueries
appears twice, it means the subqueries are optimized twice.
Oh, got it, you actually mean OptimizeSubqueries
is applied twice (here and Optimizer
). I thought that by running OptimizeSubqueries
itself here breaks some rules which cannot run twice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This partially revert looks good. Maybe we can consider https://github.com/apache/spark/pull/38626/files#r1021139971 too later.
thanks for review, merging to master! |
The failed test is known to be flaky:
|
### What changes were proposed in this pull request? This is a followup of apache#38557 . We found that some optimizer rules can't be applied twice (those in the `Once` batch), but running the rule `OptimizeSubqueries` twice breaks it as it optimizes subqueries twice. This PR partially reverts apache#38557 to still invoke `OptimizeSubqueries` in `RowLevelOperationRuntimeGroupFiltering`. We don't fully revert apache#38557 because it's still beneficial to use IN subquery directly instead of using DPP framework as there is no join. ### Why are the changes needed? Fix the optimizer. ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? N/A Closes apache#38626 from cloud-fan/follow. Authored-by: Wenchen Fan <wenchen@databricks.com> Signed-off-by: Wenchen Fan <wenchen@databricks.com>
What changes were proposed in this pull request?
This is a followup of #38557 . We found that some optimizer rules can't be applied twice (those in the
Once
batch), but running the ruleOptimizeSubqueries
twice breaks it as it optimizes subqueries twice.This PR partially reverts #38557 to still invoke
OptimizeSubqueries
inRowLevelOperationRuntimeGroupFiltering
. We don't fully revert #38557 because it's still beneficial to use IN subquery directly instead of using DPP framework as there is no join.Why are the changes needed?
Fix the optimizer.
Does this PR introduce any user-facing change?
No
How was this patch tested?
N/A