[CALCITE-3830] The ‘approximate’ field should be considered when computing the digest of AggregateCall

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.21.0
• Fix Version/s: 1.22.0
• Component/s: core
• Labels: pull-request-available
• Assignee: Shuo Cheng
• Reporter: Shuo Cheng
• Created: 27/Feb/20 02:19
• Updated: 06/Mar/20 03:15
• Resolved: 28/Feb/20 04:14

Description

In planner optimization, the digest  of Aggregate node contains digest of its AggregateCall, i.e. AggregateCall.toString, but currently the 'approximate' filed of AggregateCall is not considered in toString() method, which may leads to the situation two different relNodes are considered as identical in planner optimizing phase. 

Here is an example:

// 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])

As showing in the example, after optimizing, these two Aggregates are considered as identical (both with 89 as relNode ID).

Issue Links

• links to: GitHub Pull Request #1835