[
https://issues.apache.org/jira/browse/CALCITE-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17995712#comment-17995712
]
Silun Dong commented on CALCITE-7083:
-------------------------------------
When the {{predicate}} is not null, we can split the {{predicate}} with {{AND}}
and distinguish which ones can be pushed down and which ones cannot. This is
determined by whether the {{predicate}} references the grouping columns of
aggregate. However, this is not simply equivalent to determining whether the
index of the input ref in the {{predicate}} exists in the groupSet of the
aggregate (this is the default logic now). For example:
{code:java}
LogicalAggregate(group=[{0}], EXPR$0=[COUNT()])
LogicalProject(DEPTNO=[$7], EMPNO=[$0])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
// after CoreRules.AGGREGATE_PROJECT_MERGE
LogicalAggregate(group=[{7}], EXPR$0=[COUNT()])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
For predicate {{{}$0 > 1{}}}, it can be pushed down.
> RelMdDistinctRowCount aggregates implementation problems
> --------------------------------------------------------
>
> Key: CALCITE-7083
> URL: https://issues.apache.org/jira/browse/CALCITE-7083
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.40.0
> Reporter: Claude Brisson
> Priority: Major
>
> The default implementation of getDistinctRowCount for aggregates has several
> problems:
> - when determining the pushable predicates, it makes the assumption that the
> aggregate group key is a zero-based range, which is not necessarily the case
> (the indices in the aggregate group key are the child indices, the predicates
> are expressed in terms of the zero-based output range)
> - if there is any aggregated column in the queried group key, then it makes
> no sense to query the distinct values on the aggregate input, the handler
> should return null or (at most) the full cardinal of the aggregate
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
