-
Notifications
You must be signed in to change notification settings - Fork 28.4k
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-30842][SQL] Adjust abstraction structure for join operators #27595
Conversation
Test build #118481 has finished for PR 27595 at commit
|
sql/core/src/main/scala/org/apache/spark/sql/execution/joins/BaseJoinExec.scala
Show resolved
Hide resolved
sql/core/src/main/scala/org/apache/spark/sql/execution/joins/CartesianProductExec.scala
Outdated
Show resolved
Hide resolved
Test build #118589 has finished for PR 27595 at commit
|
@@ -286,7 +286,8 @@ abstract class SparkStrategies extends QueryPlanner[SparkPlan] { | |||
|
|||
def createCartesianProduct() = { | |||
if (joinType.isInstanceOf[InnerLike]) { | |||
Some(Seq(joins.CartesianProductExec(planLater(left), planLater(right), condition))) | |||
Some(Seq(joins.CartesianProductExec( | |||
planLater(left), planLater(right), condition))) |
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.
unnecessary change.
@@ -367,7 +368,8 @@ abstract class SparkStrategies extends QueryPlanner[SparkPlan] { | |||
|
|||
def createCartesianProduct() = { | |||
if (joinType.isInstanceOf[InnerLike]) { | |||
Some(Seq(joins.CartesianProductExec(planLater(left), planLater(right), condition))) | |||
Some(Seq(joins.CartesianProductExec( | |||
planLater(left), planLater(right), condition))) |
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.
unnecessary change.
Test build #118746 has finished for PR 27595 at commit
|
Test build #118802 has finished for PR 27595 at commit
|
sql/core/src/main/scala/org/apache/spark/sql/execution/joins/BroadcastNestedLoopJoinExec.scala
Show resolved
Hide resolved
} else "None" | ||
s""" | ||
|(${ExplainUtils.getOpId(this)}) $nodeName ${ExplainUtils.getCodegenId(this)} | ||
|${ExplainUtils.generateFieldString("Join condition", joinCondStr)} |
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.
can we include join keys here? Then we can remove the verboseStringWithOperatorId
methods in join sub-classes.
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.
And we should print nothing if join keys are empty, instead of []
.
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.
Sure, will update. Thanks!
Test build #118879 has finished for PR 27595 at commit
|
LGTM. @Eric5553 can you list the EXPLAIN output changes introduced by this PR? Thanks! |
@cloud-fan Sure
Also updated in PR description. |
@Eric5553 can you fix the conflicts? thanks! |
retest this please |
Test build #119036 has finished for PR 27595 at commit
|
Test build #119038 has finished for PR 27595 at commit
|
@cloud-fan Sure, the conflicts have been resolved. :-) |
thanks, merging to master! |
### What changes were proposed in this pull request? Currently the join operators are not well abstracted, since there are lot of common logic. A trait can be created for easier pattern matching and other future handiness. This is a follow-up PR based on comment apache#27509 (comment) . This PR refined from the following aspects: 1. Refined structure of all physical join operators 2. Add missing joinType field for CartesianProductExec operator 3. Refined codes related to Explain Formatted The EXPLAIN FORMATTED changes are 1. Converge all join operator `verboseStringWithOperatorId` implementations to `BaseJoinExec`. Join condition displayed, and join keys displayed if it’s not empty. 2. `apache#1` will add Join condition to `BroadcastNestedLoopJoinExec`. 3. `apache#1` will **NOT** affect `CartesianProductExec`,`SortMergeJoin` and `HashJoin`s, since they already got there override implementation before. 4. Converge all join operator `simpleStringWithNodeId` to `BaseJoinExec`, which will enhance the one line description for `CartesianProductExec` with `JoinType` added. 5. Override `simpleStringWithNodeId` in `BroadcastNestedLoopJoinExec` to show `BuildSide`, which was only done for `HashJoin`s before. ### Why are the changes needed? Make the code consistent with other operators and for future handiness of join operators. ### Does this PR introduce any user-facing change? No ### How was this patch tested? Existing tests Closes apache#27595 from Eric5553/RefineJoin. Authored-by: Eric Wu <[email protected]> Signed-off-by: Wenchen Fan <[email protected]>
What changes were proposed in this pull request?
Currently the join operators are not well abstracted, since there are lot of common logic. A trait can be created for easier pattern matching and other future handiness. This is a follow-up PR based on comment
#27509 (comment) .
This PR refined from the following aspects:
The EXPLAIN FORMATTED changes are
verboseStringWithOperatorId
implementations toBaseJoinExec
. Join condition displayed, and join keys displayed if it’s not empty.#1
will add Join condition toBroadcastNestedLoopJoinExec
.#1
will NOT affectCartesianProductExec
,SortMergeJoin
andHashJoin
s, since they already got there override implementation before.simpleStringWithNodeId
toBaseJoinExec
, which will enhance the one line description forCartesianProductExec
withJoinType
added.simpleStringWithNodeId
inBroadcastNestedLoopJoinExec
to showBuildSide
, which was only done forHashJoin
s before.Why are the changes needed?
Make the code consistent with other operators and for future handiness of join operators.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Existing tests