[
https://issues.apache.org/jira/browse/CALCITE-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16879527#comment-16879527
]
Gian Merlino commented on CALCITE-3144:
---------------------------------------
On [line 234 of
AggregateCaseToFilterRule|https://github.com/apache/calcite/compare/master...julianhyde:3144-aggregate-case-to-filter#diff-cd134ae87f288527952a2726f3bd46cbR234],
case A1 will never get to run, since allowsFilter is always false -- right? Is
that intentional? It also seems like the [new check in
AggregateCall|https://github.com/apache/calcite/compare/master...julianhyde:3144-aggregate-case-to-filter#diff-46bc04fa03f7fdc22d08f0ba97ee2087R104]
would always fail when provided with a filtered aggregator. I might be missing
something.
Other than the above, the general idea seems the same as Druid's rule, so it
looks good to me from that POV. We've been using it in production for a while.
It's quite helpful to us since in Druid's query engines, a filtered aggregator
is substantially faster than evaluating a CASE function.
> Add rule, CaseFilteredAggregatorRule, that converts "SUM(CASE WHEN b THEN x
> END)" to "SUM(x) FILTER (WHERE b)"
> --------------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-3144
> URL: https://issues.apache.org/jira/browse/CALCITE-3144
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
> Priority: Major
> Fix For: 1.21.0
>
>
> Add a rule that converts "SUM(CASE WHEN b THEN x END)" to "SUM\(x) FILTER
> (WHERE b)".
> Druid added {{CaseFilteredAggregatorRule}} in
> https://github.com/apache/incubator-druid/pull/4360.
> Maybe {{AggregateCaseToFilterRule}} is a slightly better name. Or maybe this
> transform could be done in {{RelBuilder.aggregate}}, and we wouldn't need a
> rule.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
