maropu commented on a change in pull request #32210:
URL: https://github.com/apache/spark/pull/32210#discussion_r619980616
##########
File path:
sql/core/src/main/scala/org/apache/spark/sql/execution/joins/ShuffledHashJoinExec.scala
##########
@@ -81,11 +83,22 @@ case class ShuffledHashJoinExec(
protected override def doExecute(): RDD[InternalRow] = {
val numOutputRows = longMetric("numOutputRows")
+ val spillThreshold = getSpillThreshold
+ val inMemoryThreshold = getInMemoryThreshold
+ val streamSortPlan = getStreamSortPlan
+ val buildSortPlan = getBuildSortPlan
+ val fallbackSMJPlan = SortMergeJoinExec(leftKeys, rightKeys, joinType,
condition, left, right)
+
streamedPlan.execute().zipPartitions(buildPlan.execute()) { (streamIter,
buildIter) =>
- val hashed = buildHashedRelation(buildIter)
- joinType match {
- case FullOuter => fullOuterJoin(streamIter, hashed, numOutputRows)
- case _ => join(streamIter, hashed, numOutputRows)
+ buildHashedRelation(buildIter) match {
+ case r: UnfinishedUnsafeHashedRelation =>
+ joinWithSortFallback(streamIter, buildIter, r.destructiveValues(),
streamSortPlan,
Review comment:
For example, we have three tasks for a shuffle hash join. If the two
tasks have no fallback and the last one has the fallback, the running time of
the fallback one (building time of a hash table and sorting time of left/right
input rows) can be much longer than the other two non-fallback ones? Or, I
misunderstood the current logic?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
