You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Broadcast hash join and sort-merge join can produce incorrect results on non-default collated keys [Spark 4] #4051
Follow-up from #4035, which rejects non-default collated strings in shuffle, sort, and aggregate but does not cover the join paths.
CometHashJoin.doConvert (used by both CometHashJoinExec and CometBroadcastHashJoinExec) and CometSortMergeJoinExec.supportedSortMergeJoinEqualType both accept any StringType as a join key without checking for non-default collation. Comet's native join performs byte-level key equality, so rows that compare equal under a collation (e.g., 'a' vs 'A' under utf8_lcase) will not match.
For sort-merge join this is masked today by the shuffle-side fallback added in #4035: the shuffle on a collated key falls back to Spark, which forces the whole stage to Spark. Broadcast hash join has no shuffle to protect it, so incorrect results can escape.
Steps to reproduce
With Spark 4.0.1:
SETspark.comet.exec.broadcastHashJoin.enabled = true;
CREATE OR REPLACE TEMP VIEW l ASSELECT*FROM (VALUES ('a'), ('B')) AS t(c);
CREATE OR REPLACE TEMP VIEW r ASSELECT*FROM (VALUES ('A'), ('b')) AS t(c);
SELECTl.c, r.cFROM l JOIN r
ONl.c COLLATE utf8_lcase =r.c COLLATE utf8_lcase;
Spark returns two matching rows; Comet (with broadcast hash join enabled) returns zero because the byte-level equality in the native join does not match 'a' with 'A'.
Expected behavior
Comet should fall back to Spark for hash joins and sort-merge joins whose equality keys have a non-default collation, either by rejecting the key types in supportedSortMergeJoinEqualType / a new equivalent check in CometHashJoin.doConvert, or by funneling through the existing isStringCollationType predicate on CometTypeShim.
Could I take this one? I plan to add a collation guard in CometHashJoin and a regression test for broadcast hash join and add the defensive SMJ check for consistency. Is this the correct approach? Thanks.
Activity
parthchandra commentedon Apr 23, 2026
SortMergeJoin may not be an issue since a shuffle before the join will hit the collation guard.
0lai0 commentedon Apr 25, 2026
Could I take this one? I plan to add a collation guard in CometHashJoin and a regression test for broadcast hash join and add the defensive SMJ check for consistency. Is this the correct approach? Thanks.
andygrove commentedon Apr 25, 2026
Thanks @0lai0 - I would recommend starting with repro tests to confirm that this issue is valid first