peter-toth commented on code in PR #59599:
URL: https://github.com/apache/spark/pull/59599#discussion_r4339248431
##########
sql/core/src/main/scala/org/apache/spark/sql/execution/KeyGroupedPartitionedScan.scala:
##########
@@ -18,13 +18,51 @@
package org.apache.spark.sql.execution
import org.apache.spark.sql.catalyst.InternalRow
-import org.apache.spark.sql.catalyst.expressions.RowOrdering
+import org.apache.spark.sql.catalyst.expressions.{Expression, RowOrdering}
import org.apache.spark.sql.catalyst.plans.physical.{KeyGroupedPartitioning,
KeyGroupedShuffleSpec}
import org.apache.spark.sql.catalyst.util.InternalRowComparableWrapper
import org.apache.spark.sql.execution.joins.StoragePartitionJoinParams
/** Base trait for a data source scan capable of producing a key-grouped
output. */
trait KeyGroupedPartitionedScan[T] {
+ /**
+ * Return join-key positions for `outputPartitioning`.
[[getInputPartitionGrouping]] always
+ * uses `spjParams.joinKeyPositions`. Skip output projection for a
leading-prefix subset of
+ * partition keys when common-partition metadata remains at full width;
projecting output
+ * misaligns nested siblings in a
+ * [[org.apache.spark.sql.catalyst.plans.physical.PartitioningCollection]].
+ */
+ private def joinKeyPositionsForOutput(
+ spjParams: StoragePartitionJoinParams,
+ baseExpressions: Seq[Expression]): Option[Seq[Int]] = {
+ spjParams.joinKeyPositions match {
+ case Some(pos) if pos.length < baseExpressions.length &&
Review Comment:
**Finding 3.** For a leading-prefix subset over full-width common values,
this keeps the output at full width, one partition per `(id, name)`, while
`getInputPartitionGrouping` groups the splits by the prefix. The lookup at
L219-223 wraps each full-width value with the prefix-typed `partExpressions`,
and `InternalRowComparableWrapper` compares only those leading fields, so every
`(1, *)` partition receives all `id = 1` splits.
I ran two queries with `allowJoinKeysSubsetOfPartitionKeys.enabled=true` and
`requireAllClusterKeysForCoPartition=false`, AQE on and off. `i` and `j` are
`(id INT, name STRING, price DOUBLE) PARTITIONED BY (id, name)`, both holding
`(1, 'aa')` and `(1, 'bb')`; `k` is `(id INT, v DOUBLE) PARTITIONED BY (id)`
holding ids 1 and 2.
- `SELECT * FROM i JOIN j ON i.id = j.id AND i.name = j.name JOIN k ON i.id
= k.id` returns only the `(1, 'aa')` row; the `(1, 'bb')` row is lost.
- `SELECT * FROM i LEFT ANTI JOIN j ON i.id = j.id AND i.name = j.name JOIN
k ON i.id = k.id` returns `(1, 'bb')`, although the correct result is empty.
Both are correct on `branch-4.1`, where both inner scans get position `[0]`
and the merged values. The ignored test's shape goes through the same lookup.
Projecting the common values onto the composed positions and deduping them, as
suggested in finding 1, removes the need for it; until then this layout should
fall back to a shuffle at planning time.
---
_Generated by [Claude Code](https://claude.ai/code)_
--
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]
