[jira] [Updated] (HIVE-3276) optimize union sub-queries

["Lefty Leverenz (JIRA)" <ji...@apache.org>]

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

Lefty Leverenz updated HIVE-3276:
---------------------------------

    Description: 
It might be a good idea to optimize simple union queries containing map-reduce jobs in at least one of the sub-qeuries.

For eg:

a query like:



insert overwrite table T1 partition P1
select * from 
(
  subq1
    union all
  subq2
) u;


today creates 3 map-reduce jobs, one for subq1, another for subq2 and 
the final one for the union. 

It might be a good idea to optimize this. Instead of creating the union 
task, it might be simpler to create a move task (or something like a move
task), where the outputs of the two sub-queries will be moved to the final 
directory. This can easily extend to more than 2 sub-queries in the union.

This is very useful if there is a select * followed by filesink after the
union. This can be independently useful, and also be used to optimize the
skewed joins -- 
https://cwiki.apache.org/confluence/display/Hive/Skewed+Join+Optimization.

If there is a select, filter between the union and the filesink, the select
and the filter can be moved before the union, and the follow-up job can
still be removed.

  was:
It might be a good idea to optimize simple union queries containing map-reduce jobs in at least one of the sub-qeuries.

For eg:

a query like:



insert overwrite table T1 partition P1
select * from 
(
  subq1
    union all
  subq2
) u;


today creates 3 map-reduce jobs, one for subq1, another for subq2 and 
the final one for the union. 

It might be a good idea to optimize this. Instead of creating the union 
task, it might be simpler to create a move task (or something like a move
task), where the outputs of the two sub-queries will be moved to the final 
directory. This can easily extend to more than 2 sub-queries in the union.

This is very useful if there is a select * followed by filesink after the
union. This can be independently useful, and also be used to optimize the
skewed joins https://cwiki.apache.org/Hive/skewed-join-optimization.html.

If there is a select, filter between the union and the filesink, the select
and the filter can be moved before the union, and the follow-up job can
still be removed.


> optimize union sub-queries
> --------------------------
>
>                 Key: HIVE-3276
>                 URL: https://issues.apache.org/jira/browse/HIVE-3276
>             Project: Hive
>          Issue Type: Bug
>    Affects Versions: 0.10.0
>            Reporter: Namit Jain
>            Assignee: Namit Jain
>             Fix For: 0.10.0
>
>         Attachments: HIVE-3276.1.patch, hive.3276.10.patch, hive.3276.11.patch, hive.3276.12.patch, hive.3276.13.patch, hive.3276.14.patch, hive.3276.2.patch, hive.3276.3.patch, hive.3276.4.patch, hive.3276.5.patch, hive.3276.6.patch, hive.3276.7.patch, hive.3276.8.patch, hive.3276.9.patch
>
>
> It might be a good idea to optimize simple union queries containing map-reduce jobs in at least one of the sub-qeuries.
> For eg:
> a query like:
> insert overwrite table T1 partition P1
> select * from 
> (
>   subq1
>     union all
>   subq2
> ) u;
> today creates 3 map-reduce jobs, one for subq1, another for subq2 and 
> the final one for the union. 
> It might be a good idea to optimize this. Instead of creating the union 
> task, it might be simpler to create a move task (or something like a move
> task), where the outputs of the two sub-queries will be moved to the final 
> directory. This can easily extend to more than 2 sub-queries in the union.
> This is very useful if there is a select * followed by filesink after the
> union. This can be independently useful, and also be used to optimize the
> skewed joins -- 
> https://cwiki.apache.org/confluence/display/Hive/Skewed+Join+Optimization.
> If there is a select, filter between the union and the filesink, the select
> and the filter can be moved before the union, and the follow-up job can
> still be removed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)