github-actions[bot] commented on code in PR #67152:
URL: https://github.com/apache/doris/pull/67152#discussion_r3860340405
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/rules/analysis/FillUpQualifyMissingSlot.java:
##########
@@ -135,11 +140,12 @@ public List<Rule> buildRules() {
qualify -> having -> agg
*/
RuleType.FILL_UP_QUALIFY_HAVING_AGGREGATE.build(
- logicalQualify(logicalHaving(aggregate())).then(qualify -> {
+ logicalQualify(logicalHaving(aggregate())).thenApply(ctx -> {
+ LogicalQualify<LogicalHaving<Aggregate<Plan>>> qualify =
ctx.root;
checkWindow(qualify);
Review Comment:
[P1] Preserve both correlated filters across the window project
The new outer-scope resolver makes this branch accept a correlated QUALIFY,
but the legal case with a separately correlated HAVING still fails. For `EXISTS
(SELECT i.k FROM i GROUP BY i.k HAVING o.h=1 QUALIFY row_number() OVER (ORDER
BY i.k)=1 AND o.q=1)`, normalization produces this reduced tree:
```text
Filter[QUALIFY o.q]
Project[window]
Filter[HAVING o.h]
Aggregate[i.k]
```
Subquery unnesting runs before window extraction, and filter pushdown
refuses a project containing a window expression. `UnCorrelatedApplyFilter`
therefore records only `o.q` in the APPLY; `ExistsApplyToJoin` converts with
that one predicate while `o.h` remains in the right subtree, which final slot
validation rejects. Please decorrelate/conjoin both predicates across the
window project (or reject the unsupported shape during analysis) and add the
missing `Qualify(Having(Aggregate))` regression.
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/rules/analysis/FillUpQualifyMissingSlot.java:
##########
@@ -189,7 +199,8 @@ interface PlanGenerator {
Plan apply(Set<Expression> newConjuncts, List<NamedExpression>
projects);
}
- private Plan createPlan(LogicalProject<Plan> project, Set<Expression>
conjuncts, PlanGenerator planGenerator) {
+ private Plan createPlan(LogicalProject<Plan> project, Set<Expression>
conjuncts,
+ Optional<Scope> outerScope, PlanGenerator planGenerator) {
Set<Slot> projectOutputSet = project.getOutputSet();
List<NamedExpression> newOutputSlots = Lists.newArrayList();
Set<Expression> newConjuncts = new LinkedHashSet<>();
Review Comment:
[P1] Resolve correlated producers hidden by SELECT aliases
This check misses an outer dependency hidden behind a project alias. For
`EXISTS (SELECT i.k, o.flag AS f, row_number() OVER (ORDER BY i.k) AS rn FROM i
QUALIFY rn=1 AND f=1)`, QUALIFY is bound to project-local `f`/`rn`, so both
inputs are already in `projectOutputSet` and `createPlan` returns without
exposing producer `o.flag`. Because the project contains a window expression,
filter pushdown cannot rewrite `f` back to its producer before APPLY
decorrelation. The filter therefore does not intersect correlation slot
`o.flag`, and EXISTS takes the uncorrelated path although the right project
still reads the outer slot; final validation rejects that plan. Please preserve
or resolve alias-producer dependencies for correlation extraction and cover
this alias form with a regression.
--
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]
