[
https://issues.apache.org/jira/browse/PHOENIX-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-2965:
-----------------------------------
Attachment: 2965-v11.txt
-v11 looks to be correct, but misses some optimizations. Simply checks in
static GroupBy.compile whether there are any HAVING expressions in case of an
aggregate. If so, it avoid the optimization.
As I said, this is getting fickle. Not a big fan of fragile code, much less a
fan of adding such code.
We could also just document to use {{SELECT COUNT(...) FROM (SELECT
DISTINCT(...) FROM T)}} for cases where this is possible.
> 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
> Assignee: Lars Hofhansl
> Fix For: 4.8.0
>
> Attachments: 2965-v10.txt, 2965-v11.txt, 2965-v2.txt, 2965-v3.txt,
> 2965-v4.txt, 2965-v5.txt, 2965-v6.txt, 2965-v7.txt, 2965-v8.txt, 2965-v9.txt,
> 2965.txt, PHOENIX-2965_wip.patch
>
>
> 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)
