[fix](fe) Revert semi join constraint matching fix#65546
Draft
shuke987 wants to merge 1 commit into
Draft
Conversation
### What problem does this PR solve? Issue Number: N/A Related PR: apache#65205 Problem Summary: PR apache#65205 introduced a correctness issue in leading hint planning. Revert its semi/anti join constraint matching change and the unit tests added with it to restore the previous planner behavior while a correct fix is prepared. ### Release note None ### Check List (For Author) - Test: No need to test - Exact revert verified against the parent of apache#65205; targeted FE UT was stopped to publish the revert immediately. - Behavior changed: Yes. Restore the leading hint behavior before apache#65205. - Does this need documentation: No
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
Collaborator
Author
|
run buildall |
Contributor
TPC-H: Total hot run time: 29355 ms |
Contributor
TPC-DS: Total hot run time: 180585 ms |
Contributor
ClickBench: Total hot run time: 24.98 s |
Collaborator
Author
|
/review |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Automated review result: requesting changes.
I found one correctness regression in the leading-hint semi/anti constraint matching. The PR restores the old block that can accept a semi/anti constraint after the constrained side has been split, and it also deletes the direct unit tests that covered those cases.
Critical checkpoint conclusions:
- Goal and tests: the stated goal is to revert #65205, but the resulting code does not preserve leading-hint correctness for semi/anti joins. The direct
LeadingHintTestcoverage for these cases is removed and no replacement test is added. - Scope: the code change is small, but it changes a high-risk planner invariant: semi/anti constrained-side exactness.
- Parallel paths: left/right semi and left/right anti were checked. The current guard is semi-only, uses an impossible left-side predicate, and checks the wrong full side for right semi/right anti shapes.
- Concurrency, lifecycle, config/session propagation, persistence, data writes, FE-BE protocol, and observability: not involved in this local FE planner logic change.
- Validation:
git diff --checkon the changed paths passed. I did not run FE tests because the review prompt says not to attempt builds, and this review is based on static code/path analysis. - User focus: no additional user-provided review focus was supplied.
Subagent conclusions: S1 and S2 both found the same functional regression and coverage regression. S2 was treated as duplicate/confirming evidence for S1. Convergence round C1 ended with both live subagents returning NO_NEW_VALUABLE_FINDINGS for the final ledger containing M1 as the only inline comment.
| if (joinConstraint.getJoinType().isSemiOrAntiJoin()) { | ||
| if (!LongBitmap.isSubset(joinConstraint.getMinLeftHand(), joinTableBitmap) | ||
| || !LongBitmap.isSubset(joinConstraint.getMinRightHand(), joinTableBitmap)) { | ||
| if (joinConstraint.getJoinType().isSemiJoin()) { |
Contributor
There was a problem hiding this comment.
This restores the old constrained-side bug for leading hints. For semi/anti joins the full non-retained side has to remain wholly on one child before the constraint can match, but this block now only runs for isSemiJoin(), the first predicate is impossible (isSubset(rightHand, leftTableBitmap) && !isSubset(rightHand, leftTableBitmap)), and right semi joins still check rightHand even though their constrained side is leftHand.
For example, with a left-semi constraint minLeft=A, minRight=B, leftHand=A, rightHand=B|C, a leading split left=A|C, right=B skips this guard and then matches lines 430-436 because the min hands are present, producing (A join C) LEFT_SEMI B even though C belonged to the constrained right side. Left anti follows the same path because anti joins no longer enter the guard at all. The deleted LeadingHintTest had direct cases for these semi/anti constrained-side splits, so this PR reintroduces the bad match and removes the coverage that would catch it.
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.
What problem does this PR solve?
Issue Number: N/A
Related PR: #65205
Problem Summary:
PR #65205 introduced a correctness issue in leading hint planning by changing how semi/anti join constraints are matched. This PR reverts merge commit
cbccdafa41adfff73e683ac1dfcae46638c16d48in full, restoring the previous planner behavior while a correct fix is prepared.Release note
None
Check List (For Author)
This is an exact revert of #65205. The reverted paths match the parent of the original merge commit, and
git diff --checkpassed before commit.Restores the leading hint behavior from before #65205.
Check List (For Reviewer who merge this PR)