[
https://issues.apache.org/jira/browse/PHOENIX-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15317539#comment-15317539
]
Lars Hofhansl commented on PHOENIX-2965:
----------------------------------------
Yeah, {{SELECT COUNT(1) FROM (SELECT DISTINCT foo FROM t);}} already uses the
optimization. I tried that as part of the parent. :)
It generates a slightly inferior plan, though, in that it aggregate into a
single row on the client rather than the server.
bq. Nothing is hardcoded.
In this case it is at least to some extent ... {{GroupByCompiler.compile()}},
when it sees an "empty group by" that is also an aggregate, it returns a static
prefabricated GroupBy objects {{GroupBy.UNGROUPED_GROUP_BY}}. The aggregation
currently possible with an empty group by is COUNT(DISTINCT...).
So not worth doing in the 4.8 branch?
> Use DistinctPrefixFilter logic for COUNT(DISTINCT ...) and COUNT(...) GROUP BY
> ------------------------------------------------------------------------------
>
> Key: PHOENIX-2965
> URL: https://issues.apache.org/jira/browse/PHOENIX-2965
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Lars Hofhansl
> Fix For: 4.8.0
>
>
> Parent uses skip scanning to optimize DISTINCT and certain GROUP BY
> operations along the row key.
> COUNT queries are optimized differently, could be sped up significantly as
> well.
> [~giacomotaylor], I might need to help into where COUNT(DISTINCT) queries are
> planned and optimized.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
