[
https://issues.apache.org/jira/browse/CALCITE-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shuo Cheng updated CALCITE-3830:
--------------------------------
Summary: Digest of AggregateCall do not consider the ‘approximate’
attribute (was: The 'approximate' field should be considered in
AggregateCall.toString() which is used as the digest)
> Digest of AggregateCall do not consider the ‘approximate’ attribute
> -------------------------------------------------------------------
>
> Key: CALCITE-3830
> URL: https://issues.apache.org/jira/browse/CALCITE-3830
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.21.0
> Reporter: Shuo Cheng
> Priority: Major
> Fix For: 1.22.0
>
>
> In planner optimization, the digest of Aggregate node contains digest of its
> AggregateCall, i.e. Aggregate.toString, but currently 'approximate' filed of
> AggregateCall is not considered in toString() method, which may lead to the
> situation two different relNode is considered as identical in planner
> optimizing phase.
> Here is an example:
> {code:java}
> // SQL
> select * from (
> select a, count(distinct b) from T group by a
> union all
> select a, approx_count_distinct(b) from T group by a
> )
> // after applying a rule, the plan is
> LogicalSink(name=[_DataStreamTable_1], fields=[a, EXPR$1], __id__=[96])
> +- LogicalProject(a=[$0], EXPR$1=[$1], __id__=[94])
> +- LogicalUnion(all=[true], __id__=[92])
> :- LogicalAggregate(group=[{0}], EXPR$1=[COUNT(DISTINCT $1)],
> __id__=[89])
> : +- LogicalTableScan(table=[[default, _DataStreamTable_2]],
> __id__=[100])
> +- LogicalAggregate(group=[{0}], EXPR$1=[COUNT(DISTINCT $1)],
> __id__=[89])
> +- LogicalTableScan(table=[[default, _DataStreamTable_2]],
> __id__=[100])
> {code}
> As showing in the example, after optimizing, these two Aggregates are
> considered as identical (both with 89 as relNode ID).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
