Repository navigation
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #26090 +/- ##
==========================================
- Coverage 82.91% 82.91% -0.01%
==========================================
Files 1155 1155
Lines 458091 458243 +152
Branches 458091 458243 +152
==========================================
+ Hits 379830 379945 +115
- Misses 55220 55247 +27
- Partials 23041 23051 +10 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
TinyMurky
force-pushed
the
support-null-aware-SortMergeJoinExec
branch
from
October 9, 2026 15:54
bd3306c to
1b3711b
Compare
github-actions
Bot
added
auto detected api change
TinyMurky
force-pushed
the
support-null-aware-SortMergeJoinExec
branch
2 times, most recently
from
October 14, 2026 03:17
6048d8c to
2b3d2c5
Compare
github-actions
Bot
added
optimizer
TinyMurky
force-pushed
the
support-null-aware-SortMergeJoinExec
branch
2 times, most recently
from
October 19, 2026 07:33
b76ba05 to
541942f
Compare
…distribution_requirements when null_aware is true
Pass the validated null-aware mode to the bitwise stream and initialize the subquery state. Validate single-partition inputs at execution time.
Restore the seven-argument SortMergeJoinExec::try_new constructor and enable null-aware semantics through the validated with_null_aware builder. Preserve the flag when rebuilding plans. Restore the original protobuf schema and generated types. Reject serialization of null-aware sort-merge joins rather than silently losing their semantics. Restore ordinary join test configuration and update direct stream callers to pass no null-aware mode.
Classify the inner input as empty, containing NULL keys, or nonempty without NULL keys before the merge scan. Retain the first nonempty batch at offset zero for matching. Finish null-aware LeftAnti streams without emitting rows when the inner input contains a NULL key.
Choose null-aware SortMergeJoinExec for single-key LeftAnti joins without a filter when hash joins are not preferred. Require NullEqualsNothing and request ASC NULLS FIRST ordering. Apply an outer-key validity mask to unmatched rows when the inner input is nonempty without NULL keys. Use logical_nulls to account for dictionary values that are NULL. Preserve unmatched rows when the inner input is empty.
Distinguish CollectLeft null-aware hash joins from the supported single-partition LeftAnti sort-merge path. Clarify that remaining null-aware joins retain CollectLeft mode.
Document the supported null-aware LeftAnti routing and HashJoin fallback. Use a match guard for the RHS NULL early exit without changing its behavior.
Carry the original null-aware flag through both sort-merge join key reordering constructors so rebuilt joins retain NOT IN semantics.
Expect SortMergeJoinExec for eligible NOT IN queries when hash join is not preferred. Update the regression comments to reflect null-aware sort-merge join support.
Display the null_aware marker in default, verbose, and tree plan formats when enabled. Update the existing EXPLAIN expectation and add a tree-format SQLLogicTest case for null-aware LeftAnti joins.
Add SQL regression coverage for null-aware sort-merge joins when prefer_hash_join is false. Verify that an empty RHS preserves NULL outer keys and duplicate rows, an RHS containing NULL suppresses all rows, and a nonempty RHS without NULL excludes NULL and matched outer keys. Use a four-partition RHS to verify that NULL detection covers the entire input. Assert null-aware SMJ plans with target_partitions set to 1 or 4 and with join repartitioning enabled or disabled. Verify that unsupported correlated anti joins retain the CollectLeft HashJoin fallback and that null-aware mark joins preserve UNKNOWN results when hash joins are not preferred. Update the related test comments. Refs apache#25546
Add five executor tests for null-aware LeftAnti sort-merge joins. Cover empty inputs, empty batches before RHS NULLs, startup prefetch across key groups, draining remaining left batches, and dictionary value NULLs. Use row IDs to verify that NULL and duplicate rows are retained or removed according to NOT IN semantics. Exercise batch sizes 1 and 2 at key-group boundaries and check dictionaries with valid indices pointing to NULL values and different index mappings on each side. Reuse the existing join and input helpers, with small fixture helpers modeled on the null-aware HashJoin tests. Execute plans directly so the optimizer cannot simplify away empty-input cases. Refs apache#25546
TinyMurky
force-pushed
the
support-null-aware-SortMergeJoinExec
branch
from
October 19, 2026 08:17
541942f to
8f3e360
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a draft PR, I'm still working on the issue
Which issue does this PR close?
NOT IN) anti / mark joins inSortMergeJoinExec#25546Rationale for this change
What changes are included in this PR?
What is the testing strategy for this PR?
Are there any user-facing changes?