MinJi Kim commented on CALCITE-1930:

Here is the updated PR:  https://github.com/apache/calcite/pull/510

I added some more tests to agg.iq.  Also, the changes to the 
AggregateExpandDistinctAggregatesRule to support distinct aggregate calls with 
more than one input were not that big, so I made them here.  I think it seems 
to work fine now, so I added tests in both RelOptRulesTest and agg.iq with 

> AggregateExpandDistinctAggregatesRule does not expand aggregates properly
> -------------------------------------------------------------------------
>                 Key: CALCITE-1930
>                 URL: https://issues.apache.org/jira/browse/CALCITE-1930
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>            Reporter: MinJi Kim
>            Assignee: Julian Hyde
> A query with two aggregate calls, sum(comm) and min(comm), it produces an 
> incorrect plan.  The main problem is that it fails to index the input of 
> sum(comm) and min(comm) properly.  This seems to only happen in the special 
> case where there is only one distinct aggregate call.
> {code}
> SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY 
> deptno
> {code}
> AggregateExpandDistinctAggregatesRule produces the following plan in this 
> case.
> {code}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)], 
> EXPR$3=[SUM($1)])
>   LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
>     LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
>       LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> In the above plan, the top LogicalAggregate EXPR$1=[SUM($3]] is incorrect, it 
> should be SUM($2).

This message was sent by Atlassian JIRA

Reply via email to