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 :
// SQL
SELECT
SUM(comm), COUNT(DISTINCT sal) FILTER (WHERE sal > 1000)
FROM emp
current plan is:
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]])
But actually, the expected or correct plan is:
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]])