[ 
https://issues.apache.org/jira/browse/HIVE-19586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

slim bouguerra updated HIVE-19586:
----------------------------------
    Attachment: HIVE-19586.2.patch

> Optimize Count(distinct X) pushdown based on the storage capabilities 
> ----------------------------------------------------------------------
>
>                 Key: HIVE-19586
>                 URL: https://issues.apache.org/jira/browse/HIVE-19586
>             Project: Hive
>          Issue Type: Improvement
>          Components: Druid integration, Logical Optimizer
>            Reporter: slim bouguerra
>            Assignee: slim bouguerra
>            Priority: Major
>             Fix For: 3.0.0
>
>         Attachments: HIVE-19586.2.patch, HIVE-19586.patch
>
>
> h1. Goal
> Provide a way to rewrite queries with combination of COUNT(Distinct) and 
> Aggregates like SUM as a series of Group By.
> This can be useful to push down to Druid queries like 
> {code}
>  select count(DISTINCT interval_marker), count (distinct dim), sum(num_l) 
> FROM druid_test_table GROUP  BY `__time`, `zone` ;
> {code}
> In general this can be useful to be used in cases where storage handlers can 
> not perform count (distinct column)
> h1. How to do it.
> Use the Calcite rule {code} 
> org.apache.calcite.rel.rules.AggregateExpandDistinctAggregatesRule{code} that 
> breaks down Count distinct to a single Group by with Grouping sets or 
> multiple series of Group by that might be linked with Joins if multiple 
> counts are present.
> FYI today Hive does have a similar rule {code} 
> org.apache.hadoop.hive.ql.optimizer.calcite.rules.HiveExpandDistinctAggregatesRule{code},
>  but it only provides a rewrite to Grouping sets based plan.
> I am planing to use the actual Calcite rule, [~ashutoshc] any concerns or 
> caveats to be aware of?
> h2. Concerns/questions
> Need to have a way to switch between Grouping sets or Simple chained group by 
> based on the plan cost. For instance for Druid based scan it makes always 
> sense (at least today) to push down a series of Group by and stitch result 
> sets in Hive later (as oppose to scan everything). 
> But this might be not true for other storage handler that can handle Grouping 
> sets it is better to push down the Grouping sets as one table scan.
> Am still unsure how i can lean on the cost optimizer to select the best plan, 
> [~ashutoshc]/[~jcamachorodriguez] any inputs?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to