Hi,
Gently reminder about review.
On 04.10.2021 20:30, Taras Ledkov wrote:
Hi,
Please review the patch for the issue CALCITE-4818 [1], see PR#2560 [2].
Looks like the rule 'AggregateExpandDistinctAggregatesRule' contains
another bug with inferring result type of the top aggregate calls.
e.g.
If the type system expand sum type like postgress:
SUM(TINYINT | SMALLINT | INTEGER) -> BIGINT
SUM(BIGINT) -> DECIMAL
The query:
SELECT SUM(i), SUM(DISTINCT i) FROM TBL;
where i - INTEGER field.
produces the plan:
LogicalProject(EXPR$0=[CAST($0):BIGINT], EXPR$1=[$1])
LogicalAggregate(group=[{}], EXPR$0=[SUM($1)], EXPR$1=[SUM($0)]) -->
RowType[DECIMAL, BIGINT]
LogicalAggregate(group=[{0}],
EXPR$0=[SUM($0)]) --> RowType[INTEGER,
BIGINT]
LogicalProject(COMM=[$6])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
But the rule ignores the change row type in the bottom aggregate.
I propose the simple fix: pass 'null' type to the
'AggregateCall.create' call to infer aggregate type from the input.
[1]. https://issues.apache.org/jira/browse/CALCITE-4818
[2]. https://github.com/apache/calcite/pull/2560
--
Taras Ledkov
Mail-To: tled...@gridgain.com
