Uh oh!
There was an error while loading. Please reload this page.
[feat](join) support outer join reorder in dphyper - #61146
Conversation
hello-stephen
commented
Mar 9, 2026
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
starocean999
commented
Mar 9, 2026
run buildall |
starocean999
commented
Mar 9, 2026
run buildall |
doris-robot
commented
Mar 9, 2026
TPC-H: Total hot run time: 28409 ms |
doris-robot
commented
Mar 9, 2026
TPC-DS: Total hot run time: 151599 ms |
hello-stephen
commented
Mar 9, 2026
FE UT Coverage ReportIncrement line coverage |
starocean999
commented
Mar 9, 2026
run buildall |
doris-robot
commented
Mar 9, 2026
TPC-H: Total hot run time: 27382 ms |
doris-robot
commented
Mar 9, 2026
TPC-DS: Total hot run time: 152511 ms |
hello-stephen
commented
Mar 9, 2026
FE UT Coverage ReportIncrement line coverage |
starocean999
commented
Mar 11, 2026
run buildall |
doris-robot
commented
Mar 11, 2026
TPC-H: Total hot run time: 27761 ms |
doris-robot
commented
Mar 11, 2026
TPC-DS: Total hot run time: 152906 ms |
hello-stephen
commented
Mar 11, 2026
FE UT Coverage ReportIncrement line coverage |
starocean999
commented
Mar 13, 2026
run buildall |
doris-robot
commented
Mar 13, 2026
TPC-H: Total hot run time: 26927 ms |
doris-robot
commented
Mar 13, 2026
TPC-DS: Total hot run time: 167112 ms |
starocean999
commented
Mar 16, 2026
run buildall |
hello-stephen
commented
Mar 16, 2026
FE UT Coverage ReportIncrement line coverage |
doris-robot
commented
Mar 16, 2026
TPC-H: Total hot run time: 26865 ms |
doris-robot
commented
Mar 16, 2026
TPC-DS: Total hot run time: 167837 ms |
hello-stephen
commented
Mar 16, 2026
FE UT Coverage ReportIncrement line coverage |
starocean999
commented
Mar 17, 2026
run buildall |
doris-robot
commented
Mar 17, 2026
TPC-H: Total hot run time: 26922 ms |
doris-robot
commented
Mar 17, 2026
TPC-DS: Total hot run time: 168082 ms |
starocean999
commented
May 7, 2026
run buildall |
Uh oh!
There was an error while loading. Please reload this page.
…der to merge consecutive projects (#64409) Related PR: (#61146) After DPHyp join reorder, the ColumnPruning rule may produce consecutive Project nodes in the plan tree. Subsequent optimization rules expect normalized plan shapes and may not handle chains of consecutive projects correctly, leading to plan corruption or incorrect results. This is because the DPHyp reorder path runs a separate rewrite pipeline (pushDownRewrite → columnPrune) on the reordered plan before re-inserting it into the memo. Unlike the main rewrite pipeline which includes MergeProjectable in its standard rule sequence, the DPHyp post-reorder pipeline omitted this cleanup step. Fix: Add MergeProjectable after ColumnPruning in the DPHyp rewrite pipeline within Optimizer.dpHypOptimize(). This ensures that any consecutive Project nodes generated by column pruning are merged into a single project, maintaining a normalized plan shape for downstream rules.
…es on nullable side of outer join (#65682) Related PR: #61146 #### Problem Summary: When enable_dphyp_optimizer=true, DPHyp join reorder can produce wrong results for queries where the nullable side of an outer join contains Alias/Project expressions with functions like COALESCE, IFNULL, or CAST(COALESCE(...)). #### Root Cause: HyperGraph.Builder.addAlias() unconditionally adds all aliases to aliasReplaceMap, including those defined on the nullable side of outer joins. This causes their defining expressions to be "unwrapped" and later reconstructed by PlanReceiver.proposeProject() ABOVE the outer join via finalProjects. The expression then operates on null-extended values, changing semantics — e.g., COALESCE(NULL, 0) = 0 instead of the correct NULL for non-matching outer join rows. #### Fix: Added an isNullableSide context flag that propagates through buildForDPhyper() and addAlias() during graph construction. When processing an outer join: LEFT OUTER JOIN → right child flagged as nullable RIGHT OUTER JOIN → left child flagged as nullable FULL OUTER JOIN → both children flagged as nullable The flag propagates through nested projects and inner joins Aliases on the nullable side are not added to aliasReplaceMap, preserving the original Project boundary below the outer join so that expressions execute before null-extension.
…es on nullable side of outer join (apache#65682) Related PR: apache#61146 #### Problem Summary: When enable_dphyp_optimizer=true, DPHyp join reorder can produce wrong results for queries where the nullable side of an outer join contains Alias/Project expressions with functions like COALESCE, IFNULL, or CAST(COALESCE(...)). #### Root Cause: HyperGraph.Builder.addAlias() unconditionally adds all aliases to aliasReplaceMap, including those defined on the nullable side of outer joins. This causes their defining expressions to be "unwrapped" and later reconstructed by PlanReceiver.proposeProject() ABOVE the outer join via finalProjects. The expression then operates on null-extended values, changing semantics — e.g., COALESCE(NULL, 0) = 0 instead of the correct NULL for non-matching outer join rows. #### Fix: Added an isNullableSide context flag that propagates through buildForDPhyper() and addAlias() during graph construction. When processing an outer join: LEFT OUTER JOIN → right child flagged as nullable RIGHT OUTER JOIN → left child flagged as nullable FULL OUTER JOIN → both children flagged as nullable The flag propagates through nested projects and inner joins Aliases on the nullable side are not added to aliasReplaceMap, preserving the original Project boundary below the outer join so that expressions execute before null-extension.
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)