[fix](mark join) Fix invalid semi-join transpose when the bottom join is a mark join - #66574
Merged
Merged
Conversation
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
Contributor
Author
|
run buildall |
Contributor
TPC-H: Total hot run time: 28806 ms |
Contributor
TPC-DS: Total hot run time: 159090 ms |
Contributor
ClickBench: Total hot run time: 24.05 s |
Contributor
FE Regression Coverage ReportIncrement line coverage |
Contributor
Author
|
/review |
Contributor
There was a problem hiding this comment.
Review opinion: the change looks good, and I found no blocking or distinct inline issue.
Checkpoint conclusions:
- Goal and proof: the PR prevents
SemiJoinSemiJoinTransposeProjectfrom moving a top semi/anti predicate below the bottom mark slot that it consumes. The new rule test constructs the exact unsafe tree. Without the guard, exploration insertsnewBottomSemi(A, C)with the mark ExprId still in its conjuncts;PlanChecker.matches()validates every memo expression and would fail on that invalid alternative. The existing mark-join test remains the complementary positive case and proves a safe transpose is still generated. - Scope and clarity: the production change is a focused predicate plus a direct negative unit test. The comments explain the producer/consumer inversion and why rejection is required.
- Data correctness and error handling:
LogicalJoin.getExpressions()covers hash, other, and mark conjuncts, while recursive input-slot collection detects direct and nested uses of the bottom marker. Rejecting the transform prevents the downstreamslot not from childrenfailure rather than hiding or weakening it; valid plans and existing error propagation are unchanged. - Concurrency: this is a stateless planner-rule predicate over an immutable matched plan. It introduces no shared mutable state, thread interaction, locks, or atomic-ordering concern.
- Lifecycle and static initialization: no resource lifecycle, ownership cycle, or cross-translation-unit/static initialization behavior is added.
- Configuration: no configuration item or dynamic-update behavior is involved.
- Compatibility: no FE/BE protocol, function symbol, persisted metadata, storage format, or rolling-upgrade contract changes.
- Parallel paths and rule staging: the guarded rule remains registered in the applicable Cascades reorder sets. The related logical-inner/outer-over-semi exploration rule already applies the mark-slot reorder precondition; registered rewrite/exploration siblings use different ownership/type shapes or reject mark joins, so no bypass of this semi/semi failure path was found. Rejection happens before plan creation and does not mutate reorder masks or introduce a loop.
- Special condition: the check is appropriately narrow. It rejects only references to the bottom join's own mark ExprId, while allowing top-project-only uses and markers produced inside
Athat remain available after the transpose. - Tests and results: the added FE JUnit case is deterministic, reaches every pre-existing rule guard, and distinguishes base from head through memo-wide validation. No regression
.outfile is applicable. Per the review-runner instruction, I did not run a local build; live checks on headbe41d10980d9bb66eee9979ab8e1b695f1a659a0report Compile, CheckStyle, FE UT, P0 Regression, and NonConcurrent Regression passing. - Observability: no new runtime path needs logging or metrics; existing plan validation and explain/debug facilities are sufficient.
- Persistence, transactions, and writes: no EditLog, failover, transaction, data-write, visibility-version, or delete-bitmap behavior is involved.
- Cross-layer variables: no new FE-to-BE variable or scattered serialization/sending path is introduced.
- Performance: the added work is a short scan of matched join conjunct input ExprIds, whose per-expression slot sets are cached; no material CPU, allocation, or optimizer-search regression was found.
- Other issues: the complete changed-file sweep, upstream/downstream trace, sibling-rule sweep, and final unresolved-candidate audit found no additional correctness, lifecycle, compatibility, coverage, or performance issue.
User focus: review_focus.txt supplied no additional focus, so the review covered the complete PR without extra narrowing.
Review completion: Round 1 converged after the main risk scan, two normal full-coverage reviews, and a separate risk-focused review all found no new valuable issue. Proposed inline comments: 0.
starocean999
marked this pull request as ready for review
August 10, 2026 01:59
starocean999
requested review from
924060929,
englefly and
morrySnow
as code owners
August 10, 2026 01:59
morrySnow
approved these changes
Aug 10, 2026
github-actions Bot
pushed a commit
that referenced
this pull request
Aug 10, 2026
… is a mark join (#66574) ### What problem does this PR solve? Problem Summary: A query with a subquery inside the ON condition of an anti join failed at physical planning with "A expression contains slot not from children", e.g.: ```sql SELECT t1.* FROM t1 LEFT ANTI JOIN t2 ON t1.k2 = t2.k3 AND t1.k1 NOT IN (SELECT t3.k1 FROM t3 WHERE t1.k2 = t3.k2); ``` The subquery is unnested into a mark join `(t1 LEFT ANTI JOIN t3)` that produces a mark slot, and the outer anti join references the mark slot in its conjuncts. Root cause: the exploration rule `SemiJoinSemiJoinTransposeProject` transposes two nested left semi/anti joins `(A ⟕̸ B) ⟕̸ C` into `(A ⟕̸ C) ⟕̸ B`. When the bottom join `(A ⟕̸ B)` is a mark join, the transposed plan builds `newBottomSemi = (A ⟕̸ C)` from the top join, inheriting the top join's conjuncts that reference the bottom mark slot, while the mark slot is now produced above by the new top mark join. The mark slot is therefore referenced by a join whose children don't output it, and physical planning fails with "slot not from children". The fix rejects the transpose when the bottom semi join is a mark join and the top semi join references the bottom mark slot in its conjuncts, so the mark join is always kept below the join that consumes the mark slot. After the fix the query above executes correctly and returns the expected result.
github-actions Bot
pushed a commit
that referenced
this pull request
Aug 10, 2026
… is a mark join (#66574) ### What problem does this PR solve? Problem Summary: A query with a subquery inside the ON condition of an anti join failed at physical planning with "A expression contains slot not from children", e.g.: ```sql SELECT t1.* FROM t1 LEFT ANTI JOIN t2 ON t1.k2 = t2.k3 AND t1.k1 NOT IN (SELECT t3.k1 FROM t3 WHERE t1.k2 = t3.k2); ``` The subquery is unnested into a mark join `(t1 LEFT ANTI JOIN t3)` that produces a mark slot, and the outer anti join references the mark slot in its conjuncts. Root cause: the exploration rule `SemiJoinSemiJoinTransposeProject` transposes two nested left semi/anti joins `(A ⟕̸ B) ⟕̸ C` into `(A ⟕̸ C) ⟕̸ B`. When the bottom join `(A ⟕̸ B)` is a mark join, the transposed plan builds `newBottomSemi = (A ⟕̸ C)` from the top join, inheriting the top join's conjuncts that reference the bottom mark slot, while the mark slot is now produced above by the new top mark join. The mark slot is therefore referenced by a join whose children don't output it, and physical planning fails with "slot not from children". The fix rejects the transpose when the bottom semi join is a mark join and the top semi join references the bottom mark slot in its conjuncts, so the mark join is always kept below the join that consumes the mark slot. After the fix the query above executes correctly and returns the expected result.
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
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.
What problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
A query with a subquery inside the ON condition of an anti join failed at
physical planning with "A expression contains slot not from children", e.g.:
The subquery is unnested into a mark join
(t1 LEFT ANTI JOIN t3)that producesa mark slot, and the outer anti join references the mark slot in its conjuncts.
Root cause: the exploration rule
SemiJoinSemiJoinTransposeProjecttransposestwo nested left semi/anti joins
(A ⟕̸ B) ⟕̸ Cinto(A ⟕̸ C) ⟕̸ B. When thebottom join
(A ⟕̸ B)is a mark join, the transposed plan buildsnewBottomSemi = (A ⟕̸ C)from the top join, inheriting the top join's conjunctsthat reference the bottom mark slot, while the mark slot is now produced above by
the new top mark join. The mark slot is therefore referenced by a join whose
children don't output it, and physical planning fails with "slot not from
children".
The fix rejects the transpose when the bottom semi join is a mark join and the
top semi join references the bottom mark slot in its conjuncts, so the mark join
is always kept below the join that consumes the mark slot. After the fix the
query above executes correctly and returns the expected result.
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)