[jira] [Created] (CALCITE-6143) RelBuilder.aggregate pruneInputOfAggregate+dedupAggregateCalls blocks can be wrong if both trigger

["Steven Talbot (Jira)" <ji...@apache.org>]

Steven Talbot created CALCITE-6143:
--------------------------------------

             Summary: RelBuilder.aggregate pruneInputOfAggregate+dedupAggregateCalls blocks can be wrong if both trigger
                 Key: CALCITE-6143
                 URL: https://issues.apache.org/jira/browse/CALCITE-6143
             Project: Calcite
          Issue Type: Bug
            Reporter: Steven Talbot


{code:java}
// pseudo-code repro case
b.scan("table")
  .project(b.field(0), b.field(1), b.field(2))
  .aggregate(b.groupKey(ImmutableBitSet.of(1)), b.aggregateCall(SUM, b.field(2)), b.aggregatecall(SUM, b.field(2))){code}
^^ easier to see the change that introduced the bug in some ways than think about a repro, basically [https://github.com/apache/calcite/commit/de4631f62cc06b22199c1c14b687ea8a06ea06ec#diff-3be99bddc7edf13dc8198da7425d7e97c97237e3561c263fd74903b4a42d8cd9R2434] refactored "groupSet" to a 'final' var, but missed the last use at the bottom of the method for dedupAggregate. So if we get to that point, [https://github.com/apache/calcite/blame/379f41d3be465992328d5659ea62b8355e0399d1/core/src/main/java/org/apache/calcite/tools/RelBuilder.java#L2511] the aggregate gets re-built with the original groupSet, ignoring any permutation that happened to groupSet2 in the aggregate pruning.

Obviously one can workaround by turning one of these configs off, but they're both on by default so this is a bit of a landmine in Calcite 1.35, since it's unlikely to be caught by a test until someone writes a specific sort of query in production.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)