github-actions[bot] commented on code in PR #67940:
URL: https://github.com/apache/doris/pull/67940#discussion_r4057037127
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/rules/analysis/SubExprAnalyzer.java:
##########
@@ -125,7 +127,43 @@ public Expression visitInSubquery(InSubquery expr, T
context) {
AnalyzedResult analyzedResult = analyzeSubquery(expr);
checkOutputColumn(analyzedResult.getLogicalPlan());
- checkNoCorrelatedSlotsUnderAgg(analyzedResult);
+ // the correlated predicate of an IN subquery may sit below the
aggregation of the subquery:
+ // the rewrite which unnests it (UnCorrelatedApplyAggregateFilter)
computes the aggregation
+ // of the domain of every outer row, the empty correlated domain
included, so that the value
+ // which the IN compares exists for every outer row
+ if (analyzedResult.isCorrelated()) {
+ // The rewrite only carries the outer slots through the filters of
the subquery: it keeps
+ // the aggregation of the domain as it is (the outer predicate
becomes the condition
+ // which pairs the outer row with the rows of the domain) and it
reads the value which
+ // the IN compares from the aggregation itself. An outer slot
which the subquery reads
+ // from its aggregation, its projections or its joins is therefore
rejected here, the way
+ // the scalar subquery path rejects it (see visitScalarSubquery):
the subquery of
+ //
+ // select k from o where k in (select sum(i.v + o.k) from i)
+ //
+ // cannot be unnested, because the aggregation of the domain of an
outer row would have
+ // to aggregate the value of the outer row as well, and the plan
of the rewrite would
+ // read that value from a scan which does not produce it.
+
validateTheNodesOfTheSubqueryReadTheOuterSlotsThroughFilters(analyzedResult.getLogicalPlan(),
+ new
CorrelatedSlotsValidator(ImmutableSet.copyOf(analyzedResult.correlatedSlots)));
+ if (containsAWindow(analyzedResult.getLogicalPlan())) {
Review Comment:
[P1] Reject nested LIMIT/TOPN or LATERAL VIEW wrappers that the aggregate-IN
rewrite cannot rebuild. A valid correlated query such as `o.k IN (SELECT max(c)
FROM (SELECT count(*) c FROM i WHERE i.k=o.k GROUP BY i.g LIMIT 1) x)` (and the
analogous derived aggregate followed by `LATERAL VIEW explode(...)`) now passes
`visitInSubquery`: `checkRootIsLimit` checks only the root and the validator
does not reject these nested nodes. `locateAggregate` stops at the nested
`LogicalLimit`/`LogicalGenerate`, so no rule moves `i.k=o.k` into the Apply.
`InApplyToJoin` then emits only the value equality while the retained
right-side Filter still reads the outer slot, leaving an invalid subtree for
`CheckAfterRewrite` rather than a planning error or correct result. Please
reject these wrappers anywhere in the aggregate chain or preserve them per
correlation key, and add a planning oracle for both shapes.
--
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]
