You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support decorrelating subqueries with a correlated filter below the nullable side of an outer join #25789
Is your feature request related to a problem or challenge?
#25764 (which fixes #25507) stops PullUpCorrelatedExpr from pulling a correlated filter out from under the side of an outer join that gets NULL-extended, because that gave wrong results. Those subqueries now stay correlated and fail with a not-implemented error:
CREATETABLEo(k INT) ASVALUES (1), (5);
CREATETABLEa(id INT) ASVALUES (1), (2);
CREATETABLEb(id INT, y INT) ASVALUES (1, 1), (2, 2);
SELECTo.k,
EXISTS (SELECT1FROM a LEFT JOIN (SELECT*FROM b WHEREb.y=o.k) AS b
ONa.id=b.idWHEREb.y IS NULL) AS e
FROM o ORDER BY k;
-- expected (DuckDB): (1, true), (5, true)-- now: This feature is not implemented: Physical plan does not support logical expression Exists(...)
The same applies to IN, WHERE [NOT] EXISTS, scalar subqueries, the left side of a RIGHT JOIN, either side of a FULL JOIN, a correlated filter nested under an inner join on the nullable side, and LATERAL subqueries (which fail with the OuterReferenceColumn not-implemented error). The sqllogictest cases added in #25764 (subquery.slt, lateral_join.slt) cover all of these.
Describe the solution you'd like
Run these queries and return the right rows. Since the filter cannot move above the join, the outer relation has to be brought down to the filter: join the distinct outer keys into the nullable input, add the outer key columns to the join condition, and group or semi-join on them above. This is the dependent join approach from Neumann and Kemper, "Unnesting Arbitrary Queries".
DuckDB 1.5.5 returns the right results for the LEFT and RIGHT cases. For the FULL case it fails with "Unsupported join type for flattening correlated subquery".
Describe alternatives you've considered
Keep the not-implemented error. It no longer returns wrong rows, but these are valid queries that DuckDB runs.
in my opinion WE SHOULD NOT try and extend the existing subquery rewrites to support this type of query as that risks introducing many more wrong results, see #5492 (comment)
Activity
mohitgurav20 commentedon Sep 27, 2026
take
alamb commentedon Oct 28, 2026
I think we should implement support support for this feature as part of the more general subquery decorrelation project described here
in my opinion WE SHOULD NOT try and extend the existing subquery rewrites to support this type of query as that risks introducing many more wrong results, see #5492 (comment)