jayzhan211 opened a new issue, #25708:
URL: https://github.com/apache/datafusion/issues/25708

   ### Is your feature request related to a problem or challenge?
   
   Follow-up to #25529 (fix for #25519).
   
   To stop wrong results, #25529 keeps a correlated filter below an aggregate 
with a grouping set unless every set already groups by each column the pull up 
would add. That guard is conservative: it also rejects non-empty sets that 
leave out the correlated column. On `main` those queries were answered 
correctly, and with #25529 they fail to plan:
   
   ```sql
   CREATE TABLE o(k INT) AS VALUES (1), (2), (NULL), (4), (5);
   CREATE TABLE i(k INT, j INT) AS VALUES (1, 10), (NULL, 20), (5, 30), (2, 40);
   
   SELECT o.k FROM o
   WHERE EXISTS (
     SELECT 1 FROM i WHERE i.k = o.k
     GROUP BY GROUPING SETS ((i.k), (i.j))
   )
   ORDER BY o.k;
   -- with #25529: This feature is not implemented: Physical plan does not 
support logical expression Exists(...)
   ```
   
   Because the filter `i.k = o.k` fixes `i.k` to one value per outer row, 
adding `i.k` to a non-empty set that lacks it leaves the rows of each outer row 
unchanged. Only two things change: the value of `i.k` in those rows (NULL 
becomes `o.k`) and `__grouping_id`. So the old rewrite was wrong only when 
something above the aggregate reads the NULL-filled column or `GROUPING()`. One 
such case is `HAVING i.k IS NULL`, which is covered in `subquery.slt`.
   
   ### Describe the solution you'd like
   
   Decorrelate these queries again without bringing back the wrong results. Two 
options:
   
   1. Add the correlated column to each set that lacks it under an alias, so 
the column the query reads keeps its NULL fill and the join key is a separate 
column.
   2. Reject only when a set is empty (`ROLLUP`/`CUBE` always contain one) or 
when a node above the aggregate reads the NULL-filled column or `GROUPING()`.
   
   Empty sets must stay rejected: they yield a row for outer rows that match 
nothing, and a join cannot produce that row.
   
   ### Describe alternatives you've considered
   
   Keep the current guard. The queries fail to plan instead of returning wrong 
results.
   
   ### Additional context
   
   The guard is in the `Aggregate` arm of `PullUpCorrelatedExpr::f_up`, 
`datafusion/optimizer/src/decorrelate.rs`. The known limitation is documented 
in `datafusion/sqllogictest/test_files/subquery.slt`.
   


-- 
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]

Reply via email to