github-actions[bot] commented on code in PR #65682:
URL: https://github.com/apache/doris/pull/65682#discussion_r3600123248
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/jobs/joinorder/hypergraphv2/HyperGraph.java:
##########
@@ -385,15 +478,41 @@ public boolean addAlias(Alias alias, long subTreeNodes) {
if (bitmap == 0) {
bitmap = subTreeNodes;
addToReplaceMap = false;
- List<NamedExpression> aliasList =
nodeToLiteralAlias.get(bitmap);
- if (aliasList == null) {
- aliasList = new ArrayList<>(1);
- nodeToLiteralAlias.put(bitmap, aliasList);
+ // Constant aliases go into the current Project layer (set up
by
+ // buildForDPhyper) and will be flushed to
nodeToProjectedAliases
+ // keyed by the layer's subtree bitmap after the Project is
processed.
+ if (currentProjectedAliasLayer != null) {
+ currentProjectedAliasLayer.add(alias);
}
- aliasList.add(alias);
}
Preconditions.checkArgument(bitmap > 0, "slot must belong to some
table");
- slotToHyperNodeMap.put(aliasSlot, bitmap);
+ // Map nullable-side alias slots to subTreeNodes instead of the
minimal
+ // referenced bitmap. Otherwise a later join predicate like s=C.k
sees s as
+ // {B} (its input slot) and creates a {B}--{C} edge, allowing
DPHyp to join
+ // B and C before A — but s can only be emitted when {A,B} is
complete.
+ // Using subTreeNodes (e.g. {A,B}) forces the predicate edge to
require the
+ // full source subtree, matching the emission key in
nodeToProjectedAliases.
+ slotToHyperNodeMap.put(aliasSlot, isNullableSide ? subTreeNodes :
bitmap);
Review Comment:
[P2] Keep forwarding aliases on their minimal endpoint
This maps even a bare forwarding alias to the whole nullable-side Project
subtree. In the reduced tree below, `s` is exactly `A.k`, but `s = C.k` becomes
a `{A,B}--{C}` hyperedge, so DPHyp cannot form the potentially selective
`{A,C}` join before B:
```text
X LEFT JOIN
X
InnerJoin(s = C.k)
Project(A.k AS s)
InnerJoin(A, B)
C
```
Substituting a bare Slot alias within this subtree preserves values and
evaluation count; the ancestor outer join still null-extends the eventual
output. Please track the output materialization boundary separately while
keeping consumers of safe Slot-forwarding aliases on the underlying slot
bitmap, rather than forcing every alias consumer to the full source subtree.
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/jobs/joinorder/hypergraphv2/receiver/PlanReceiver.java:
##########
@@ -293,27 +293,56 @@ private LogicalPlan proposeProject(LogicalPlan join,
List<Edge> edges, long left
Set<Slot> outputSet = join.getOutputSet();
// calculate required columns by all parents
Set<Slot> requireSlots = calculateRequiredSlots(left, right, edges);
+ // Pending projected aliases may reference input slots (e.g., A.v, B.v
for
+ // s=A.v+B.v) that are not in finalRequiredSlots or unused edges.
Preserve
+ // them so the join output still contains the base columns needed to
evaluate
+ // the alias expressions, both for aliases emitted at this stage and
those
+ // deferred to a later join whose bitmap is a superset.
+ requireSlots.addAll(hyperGraph.getAllAliasInputSlotsForNodes(
Review Comment:
[P2] Drop alias inputs after their layer materializes
The overlap helper adds every alias input to `requireSlots` even after that
alias's bitmap is wholly contained in a completed child, and the same set is
copied into the emitted layer at lines 336-340. For example, `Project[B.k,
length(B.payload) AS dv]` is rebuilt as `[dv, B.k, B.payload]`; every ancestor
join then keeps `B.payload` because this helper still overlaps `{B}`, although
the original Project dropped it. A wide payload therefore crosses later
shuffles/hash tables until the final root Project. Please separate inputs
needed to evaluate current/pending layers from outputs still needed above them,
and stop retaining a layer's raw inputs once it has materialized.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
