[SPARK-37328][SQL] OptimizeSkewedJoin should work for complex queries with multiple joins#34974
Closed
cloud-fan wants to merge 1 commit into
Closed
[SPARK-37328][SQL] OptimizeSkewedJoin should work for complex queries with multiple joins#34974cloud-fan wants to merge 1 commit into
cloud-fan wants to merge 1 commit into
Conversation
Contributor
Author
|
Kubernetes integration test starting |
|
Kubernetes integration test status failure |
|
Test build #146441 has finished for PR 34974 at commit
|
ulysses-you
approved these changes
Dec 22, 2021
Contributor
ulysses-you
left a comment
There was a problem hiding this comment.
I agree with removing this check as I mentioned before, and without the check I think we can also support to optimize the skew join through union.
Contributor
Author
|
thanks for the review, merging to master! |
cloud-fan
pushed a commit
that referenced
this pull request
Feb 9, 2022
### What changes were proposed in this pull request? #34974, solved most scenarios of data skew in union. add test for it. ### Why are the changes needed? Added tests for the following scenarios： <b>scenes 1</b> ``` Union SMJ ShuffleQueryStage ShuffleQueryStage SMJ ShuffleQueryStage ShuffleQueryStage ``` <b>scenes 2</b> ``` Union SMJ ShuffleQueryStage ShuffleQueryStage HashAggregate ``` <b>scenes 3: not yet supported, SMJ-3 will introduce a new shuffle, so SMJ-1 cannot be optimized</b> ``` Union SMJ-1 ShuffleQueryStage ShuffleQueryStage SMJ-2 SMJ-3 ShuffleQueryStage ShuffleQueryStage HashAggregate ``` ### Does this PR introduce any user-facing change? No ### How was this patch tested? Pass the added test Closes #34908 from mcdull-zhang/skewed_union. Authored-by: mcdull-zhang <work4dong@163.com> Signed-off-by: Wenchen Fan <wenchen@databricks.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
What changes were proposed in this pull request?
In #32816 , we moved the rule
OptimizeSkewedJoinfromqueryStageOptimizerRulestoqueryStagePreparationRules. This means that the input plan ofOptimizeSkewedJoinwill be the entire query plan, while before the input plan was a shuffle stage which is usually a small part of the query plan.However, to simplify the implementation,
OptimizeSkewedJoinhas a check that it will be skipped if the input plan has more than 2 shuffle stages. This is obviously problematic now, as the input plan is the entire query plan and is very likely to have more than 2 shuffles.This PR proposes to remove the check from
OptimizeSkewedJoincompletely, as it's no longer needed.Why are the changes needed?
Fix a performance regression in the master branch (not released yet)
Does this PR introduce any user-facing change?
no
How was this patch tested?
a new test