[fix](fd)drop Function dependencies from join outer side - #65982
Conversation
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
|
run buildall |
|
/review |
There was a problem hiding this comment.
Request changes: one P2 optimizer performance regression remains.
Critical checkpoint conclusions:
- Goal and correctness: the patch prevents unsafe direct functional dependencies from surviving a null-extended outer-join side, and no unsafe edge is reconstructed through unique, uniform, equality, transitive, or pruning paths. However, it also drops still-valid dependencies whose determinant contains an originally non-null child slot; see the inline finding.
- Scope and parallel paths: all 14 current join types, ASOF directionality, semi/anti/NAAJ and mark shapes were checked. The logical and physical hash-join switches agree; nested-loop recomputation blocks FD propagation. No additional path-specific issue was found.
- Tests: the changed FdTest assertions inspect only the logical plan and use NOT NULL determinants, so they codify the safe dependency loss rather than reproduce the nullable-determinant collision. The physical reset/recomputation path is not covered.
- Performance: the accepted issue prevents EliminateGroupByKey and EliminateOrderByKey from applying valid reductions. No other CPU, memory, or hot-path concern was found.
- Concurrency, lifecycle, configuration, compatibility, persistence/transactions, data writes, FE-BE propagation, and observability: not involved in this change.
- User focus: no additional focus was provided; the complete PR was reviewed.
Validation was static only. No build or test was run because the governing review prompt prohibits builds in this environment.
| case NULL_AWARE_LEFT_ANTI_JOIN: | ||
| case LEFT_OUTER_JOIN: | ||
| case ASOF_LEFT_OUTER_JOIN: | ||
| builder.addFuncDepsDG(left().getLogicalProperties().getTrait()); |
There was a problem hiding this comment.
[P2] Preserve FDs with an originally non-null determinant
This drops the nullable child's whole FD graph, including edges that remain valid after null extension. In the new test, t2.id is NOT NULL and unique, so t2.id -> t2.id2: matched rows always have a non-null id, while every unmatched row contributes (id,id2)=(NULL,NULL). Those cases cannot collide, yet this arm discards the edge and makes EliminateGroupByKey retain GROUP BY t2.id,t2.id2 (and likewise prevents redundant order-key elimination).
The actual unsafe shape needs a nullable determinant, e.g. a matched (a=NULL, coalesce(a,1)=1) plus an unmatched (NULL,NULL). Please filter nullable-side edges based on whether their determinant can be all-null in an original child row, keep the current NOT NULL-key dependency, and test that nullable collision; the mirrored physical recomputation path should be covered as well.
TPC-H: Total hot run time: 23165 ms |
TPC-DS: Total hot run time: 117085 ms |
ClickBench: Total hot run time: 18.65 s |
|
PR approved by at least one committer and no changes requested. |
What problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)