You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@hive.apache.org by "Namit Jain (JIRA)" <ji...@apache.org> on 2009/11/13 21:38:39 UTC

[jira] Created: (HIVE-933) Infer bucketing/sorting properties

Infer bucketing/sorting properties
----------------------------------

                 Key: HIVE-933
                 URL: https://issues.apache.org/jira/browse/HIVE-933
             Project: Hadoop Hive
          Issue Type: New Feature
          Components: Query Processor
            Reporter: Namit Jain
             Fix For: 0.5.0


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.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (HIVE-933) Infer bucketing/sorting properties

Posted by "Namit Jain (JIRA)" <ji...@apache.org>.

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

Namit Jain updated HIVE-933:
----------------------------

    Fix Version/s:     (was: 0.5.0)

> Infer bucketing/sorting properties
> ----------------------------------
>
>                 Key: HIVE-933
>                 URL: https://issues.apache.org/jira/browse/HIVE-933
>             Project: Hadoop Hive
>          Issue Type: New Feature
>          Components: Query Processor
>            Reporter: Namit Jain
>
> 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.
-
You can reply to this email to add a comment to the issue online.