[
https://issues.apache.org/jira/browse/HIVE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13552420#comment-13552420
]
Kevin Wilfong commented on HIVE-933:
------------------------------------
I'd considered this, and have been going back and forth on the idea, it'd be
useful for other reasons too.
I wouldn't want to do this as a partition parameter, it'd have to be a new
column in the SDS table.
I've mainly been concerned about whether or not it's worth it, given that we
can approximate it by checking if the partition is bucketed/sorted and the
table is not. I suppose consistency in the scenario you described tips the
scales, I'll add it.
> Infer bucketing/sorting properties
> ----------------------------------
>
> Key: HIVE-933
> URL: https://issues.apache.org/jira/browse/HIVE-933
> Project: Hive
> Issue Type: New Feature
> Components: Query Processor
> Reporter: Namit Jain
> Assignee: Kevin Wilfong
> Attachments: HIVE-933.1.patch.txt, HIVE-933.2.patch.txt,
> HIVE-933.3.patch.txt, HIVE-933.4.patch.txt, HIVE-933.5.patch.txt,
> HIVE-933.6.patch.txt, HIVE-933.7.patch.txt, HIVE-933.8.patch.txt,
> HIVE-933.9.patch.txt
>
>
> This is a long-term plan, and may require major changes.
> From the query, we can figure out the sorting/bucketing properties, and
> change the metadata of the destination at that time.
> However, this means that different partitions may have different metadata.
> Currently, the query plan is same for all the
> partitions of the table - we can do the following:
> 1. In the first cut, have a simple approach where you take the union all
> metadata, and create the most defensive plan.
> 2. Enhance mapredWork() to include partition specific operator trees.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
