Julian Hyde commented on CALCITE-1930:

Yes (1,1,1) and (1,1,2) will be counted separately. {{SELECT COUNT(DISTINCT x, 
y, z) FROM t}} is identical to {{SELECT COUNT(x, y, z) FROM (SELECT DISTINCT x, 
y, z FROM t)}}. And COUNT counts the number of rows for which x, y and z are 
all not null.

Can you find a query that has "multiple arguments" and therefore hits this 
issue? You don't need to fix it, just add it to agg.iq either disabled or 
giving the wrong answer.

> 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