[
https://issues.apache.org/jira/browse/HIVE-17043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16622990#comment-16622990
]
Jesus Camacho Rodriguez commented on HIVE-17043:
------------------------------------------------
[~vgarg], I had a quick look at the patch. I believe we should not have
different behavior for method in {{RelMdUniqueKeys}}, this may be misleading
moving forward.
Instead of changing the semantics of {{RelMdUniqueKeys}} method, which
currently is inferred from stats and only used to get the row count, we could
determine uniqueness using {{RelMdColumnUniqueness}}. If I remember correctly,
{{RelMdColumnUniqueness}} is the metadata provider used by other Calcite
optimizations when they need to infer whether a set of columns contains unique
values or not with guarantees, i.e., not from stats that may be imprecise.
> Remove non unique columns from group by keys if not referenced later
> --------------------------------------------------------------------
>
> Key: HIVE-17043
> URL: https://issues.apache.org/jira/browse/HIVE-17043
> Project: Hive
> Issue Type: Sub-task
> Components: Logical Optimizer
> Affects Versions: 3.0.0
> Reporter: Ashutosh Chauhan
> Assignee: Vineet Garg
> Priority: Major
> Attachments: HIVE-17043.1.patch, HIVE-17043.2.patch,
> HIVE-17043.3.patch, HIVE-17043.4.patch
>
>
> Group by keys may be a mix of unique (or primary) keys and regular columns.
> In such cases presence of regular column won't alter cardinality of groups.
> So, if regular columns are not referenced later, they can be dropped from
> group by keys. Depending on operator tree may result in those columns not
> being read at all from disk in best case. In worst case, we will avoid
> shuffling and sorting regular columns from mapper to reducer, which still
> could be substantial CPU and network savings.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
