[ https://issues.apache.org/jira/browse/HIVE-19586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16496707#comment-16496707 ]
Ashutosh Chauhan commented on HIVE-19586: ----------------------------------------- TestSSL has been flaky in the past. [~jcamachorodriguez] Shall we disable this test? > 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 > Attachments: HIVE-19586.2.patch, HIVE-19586.3.patch, > HIVE-19586.3.patch, HIVE-19586.4.patch, HIVE-19586.5.patch, > HIVE-19586.6.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)