shrirangmhalgi commented on code in PR #56243:
URL: https://github.com/apache/spark/pull/56243#discussion_r3354224966
##########
sql/core/src/main/scala/org/apache/spark/sql/execution/adaptive/CoalesceShufflePartitions.scala:
##########
@@ -90,9 +90,38 @@ case class CoalesceShufflePartitions(session: SparkSession)
extends AQEShuffleRe
}
}
+ // For groups that feed a partitioned join
(SortMergeJoin/ShuffledHashJoin), enforce a
+ // minimum partition count to avoid eliminating join parallelism.
+ // Design choice: we use a pre-coalesce floor (Option A) rather than
post-coalesce skew
+ // re-checking (Option B). Option A is simpler and avoids re-running skew
detection after
+ // coalescing. Option B would be more robust for edge cases but adds
significant complexity
+ // and can be explored as a follow-up.
+ val adjustedMinNumPartitionsByGroup =
coalesceGroups.zip(minNumPartitionsByGroup).map {
+ case (group, minNum) if group.feedsJoin =>
+ val totalSize = group.shuffleStages.flatMap(
+ _.shuffleStage.mapStats.map(_.bytesByPartitionId.sum)).sum
+ val advisorySize = advisoryPartitionSize(group)
+ if (totalSize <= advisorySize) {
+ // Tiny data: all join data fits in one advisory-sized partition, so
coalescing
+ // to 1 is fine -- no parallelism benefit from multiple partitions.
+ minNum
+ } else {
+ // When COALESCE_PARTITIONS_MIN_PARTITION_NUM is explicitly set, use
it as the floor.
+ // Otherwise, compute a data-aware floor: the number of partitions
needed to keep each
+ // partition at or below the advisory target size. The max(2, ...)
ensures we never
+ // collapse to a single reducer for join data -- for totalSize
between advisorySize and
+ // 2*advisorySize, ceil gives 1 or 2, so the floor of 2 prevents
single-partition joins.
+ val joinFloor =
conf.getConf(SQLConf.COALESCE_PARTITIONS_MIN_PARTITION_NUM)
Review Comment:
When `COALESCE_PARTITIONS_MIN_PARTITION_NUM` is explicitly set, `joinFloor`
equals that config value. But `minNum` (from the existing
`minNumPartitionsByGroup` computation above) already incorporates this config.
So `math.max(minNum, joinFloor)` is effectively a no-op in the config-set case
- both sides are the same value.
The new join-floor logic only adds value in the `.getOrElse` branch (config
NOT set). Maybe consider simplifying: if the config is explicitly set, the user
has already expressed their intent and no join-specific override is needed -
you could skip this branch entirely with an early `if
(conf.getConf(...).isEmpty`) guard. This would also make it clearer to readers
that the data-aware heuristic is the actual contribution here, not the
config-set path.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
