[
https://issues.apache.org/jira/browse/CALCITE-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shuo Cheng updated CALCITE-3721:
--------------------------------
Description:
In `AggregateExpandDistinctAggregatesRule`, when the distinct aggregate call is
rewritten using
groupingSets, the filter of the distinct aggregate call itself is lost
unexpected.
Currently, the plan of the following sql after applying
`AggregateExpandDistinctAggregatesRule` is :
{code:java}
// SQL
SELECT
SUM(comm), COUNT(DISTINCT sal) FILTER (WHERE sal > 1000)
FROM emp{code}
{color:#de350b}current plan is:{color}
{code:java}
LogicalAggregate(group=[{}], EXPR$0=[MIN($2) FILTER $4], EXPR$1=[COUNT($0)
FILTER $3])
LogicalProject(SAL=[$0], $f2=[$1], EXPR$0=[$2], $g_0=[=($3, 0)], $g_3=[=($3,
3)])
LogicalAggregate(group=[{1, 2}], groups=[[{1, 2}, {}]], EXPR$0=[SUM($0)],
$g=[GROUPING($1, $2)])
LogicalProject(COMM=[$6], SAL=[$5], $f2=[>($5, 1000)])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
But actually, the {color:#4c9aff}expected or correct plan{color} is:
{code:java}
LogicalAggregate(group=[{}], EXPR$0=[MIN($2) FILTER $4], EXPR$1=[COUNT($0)
FILTER $3])
LogicalProject(SAL=[$0], $f2=[$1], EXPR$0=[$2], $g_0=[AND(=($3, 0), IS
TRUE($1))], $g_3=[=($3, 3)])
LogicalAggregate(group=[{1, 2}], groups=[[{1, 2}, {}]], EXPR$0=[SUM($0)],
$g=[GROUPING($1, $2)])
LogicalProject(COMM=[$6], SAL=[$5], $f2=[>($5, 1000)])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
was:
In `AggregateExpandDistinctAggregatesRule`, when the distinct aggregate call is
rewritten using
groupingSets, the filter of the distinct aggregate call itself is lost
unexpected.
> Filter of distinct aggregate call is lost after applying
> `AggregateExpandDistinctAggregatesRule`
> ------------------------------------------------------------------------------------------------
>
> Key: CALCITE-3721
> URL: https://issues.apache.org/jira/browse/CALCITE-3721
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.21.0
> Reporter: Shuo Cheng
> Assignee: Shuo Cheng
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In `AggregateExpandDistinctAggregatesRule`, when the distinct aggregate call
> is rewritten using
> groupingSets, the filter of the distinct aggregate call itself is lost
> unexpected.
> Currently, the plan of the following sql after applying
> `AggregateExpandDistinctAggregatesRule` is :
> {code:java}
> // SQL
> SELECT
> SUM(comm), COUNT(DISTINCT sal) FILTER (WHERE sal > 1000)
> FROM emp{code}
> {color:#de350b}current plan is:{color}
> {code:java}
> LogicalAggregate(group=[{}], EXPR$0=[MIN($2) FILTER $4], EXPR$1=[COUNT($0)
> FILTER $3])
> LogicalProject(SAL=[$0], $f2=[$1], EXPR$0=[$2], $g_0=[=($3, 0)],
> $g_3=[=($3, 3)])
> LogicalAggregate(group=[{1, 2}], groups=[[{1, 2}, {}]], EXPR$0=[SUM($0)],
> $g=[GROUPING($1, $2)])
> LogicalProject(COMM=[$6], SAL=[$5], $f2=[>($5, 1000)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
> But actually, the {color:#4c9aff}expected or correct plan{color} is:
> {code:java}
> LogicalAggregate(group=[{}], EXPR$0=[MIN($2) FILTER $4], EXPR$1=[COUNT($0)
> FILTER $3])
> LogicalProject(SAL=[$0], $f2=[$1], EXPR$0=[$2], $g_0=[AND(=($3, 0), IS
> TRUE($1))], $g_3=[=($3, 3)])
> LogicalAggregate(group=[{1, 2}], groups=[[{1, 2}, {}]], EXPR$0=[SUM($0)],
> $g=[GROUPING($1, $2)])
> LogicalProject(COMM=[$6], SAL=[$5], $f2=[>($5, 1000)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
