You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@datafusion.apache.org by "2010YOUY01 (via GitHub)" <gi...@apache.org> on 2025/09/21 15:15:20 UTC

[I] Unexpected failure in a subquery with a filter (SQLStorm) [datafusion]

2010YOUY01 opened a new issue, #17699:
URL: https://github.com/apache/datafusion/issues/17699

   ### Describe the bug
   
   `datafusion-cli` is compiled from the latest main commit 162942016
   
   ```sh
   DataFusion CLI v50.0.0
   > CREATE TABLE orders (
       o_orderkey INT,
       o_totalprice DECIMAL(15, 2)
   );
   
   INSERT INTO orders VALUES (1, 10.00);
   
   SELECT total_spent
   FROM (
       SELECT
           SUM(o_totalprice) AS total_spent,
           COUNT(DISTINCT o_orderkey) AS order_count
       FROM orders
   ) t
   WHERE total_spent > 0;
   
   Arrow error: Invalid argument error: Invalid comparison operation: Decimal128(35, 2) > Decimal128(25, 2)
   ```
   
   ### To Reproduce
   
   _No response_
   
   ### Expected behavior
   
   _No response_
   
   ### Additional context
   
   Found by SQLStorm https://github.com/apache/datafusion/issues/17698


-- 
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: github-unsubscribe@datafusion.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org


Re: [I] Unexpected failure in a subquery with a filter (SQLStorm) [datafusion]

Posted by "alamb (via GitHub)" <gi...@apache.org>.
alamb closed issue #17699: Unexpected failure in a subquery with a filter (SQLStorm)
URL: https://github.com/apache/datafusion/issues/17699


-- 
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: github-unsubscribe@datafusion.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org


Re: [I] Unexpected failure in a subquery with a filter (SQLStorm) [datafusion]

Posted by "rkrishn7 (via GitHub)" <gi...@apache.org>.
rkrishn7 commented on issue #17699:
URL: https://github.com/apache/datafusion/issues/17699#issuecomment-3316580396

   take


-- 
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: github-unsubscribe@datafusion.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org


Re: [I] Unexpected failure in a subquery with a filter (SQLStorm) [datafusion]

Posted by "rkrishn7 (via GitHub)" <gi...@apache.org>.
rkrishn7 commented on issue #17699:
URL: https://github.com/apache/datafusion/issues/17699#issuecomment-3316615098

   Just adding some context here before I forget:
   
   This issue is occurring because there is a logical optimization rule (`single_distinct_aggregation_to_group_by`) that rewrites the query, adding a new aggregation node. Because the return type for a decimal is calculated by adding to the precision ([ref](https://github.com/apache/datafusion/blob/1629420162815e1a725b9be5344fafd1fbe2e5ff/datafusion/functions-aggregate/src/sum.rs#L190)), this occurs twice after the optimization pass. However, type coercion happens prior to all of this so the return type later on in the query plan is wrong.
   
   A simple solution would be to re-run type coercion after all optimization passes. It seems unnecessary just for this however. The new precision should only be updated once, even if there is another aggregation added (since it should be equivalent).


-- 
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: github-unsubscribe@datafusion.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org