[jira] [Updated] (HIVE-12391) SkewJoinOptimizer might not kick in if columns are renamed after TableScanOperator

["Jesus Camacho Rodriguez (JIRA)" <ji...@apache.org>]

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

Jesus Camacho Rodriguez updated HIVE-12391:
-------------------------------------------
    Summary: SkewJoinOptimizer might not kick in if columns are renamed after TableScanOperator  (was: SkewJoinOptimizer might not kick in if columns are renamed after TS)

> SkewJoinOptimizer might not kick in if columns are renamed after TableScanOperator
> ----------------------------------------------------------------------------------
>
>                 Key: HIVE-12391
>                 URL: https://issues.apache.org/jira/browse/HIVE-12391
>             Project: Hive
>          Issue Type: Bug
>          Components: Logical Optimizer
>    Affects Versions: 1.3.0, 2.0.0
>            Reporter: Jesus Camacho Rodriguez
>            Assignee: Jesus Camacho Rodriguez
>         Attachments: HIVE-12391.patch
>
>
> SkewJoinOptimizer will not kick in if the columns are just renamed after the TS e.g. by the creation of a derived table.
> To reproduce, consider the following example:
> {code}
> set hive.optimize.skewjoin.compiletime = true;
> CREATE TABLE T1(key STRING, val STRING)
> SKEWED BY (key) ON ((2)) STORED AS TEXTFILE;
> CREATE TABLE T2(key STRING, val STRING)
> SKEWED BY (key) ON ((3)) STORED AS TEXTFILE;
> {code}
> For this query, SkewJoinOptimizer kicks in:
> {code}
> SELECT a.*, b.*
> FROM T1 a JOIN T2 b
> ON a.key = b.key
> {code}
> For this one, it does not:
> {code}
> SELECT a.*, b.*
> FROM 
>   (SELECT key as k, val as v FROM T1) a
>   JOIN
>   (SELECT key as k, val as v FROM T2) b
> ON a.k = b.k;
> {code}
> The reason is that SkewJoinOptimizer does not backtrack the origin of the column. Instead it just uses its name to know if it is produced by a certain TS.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)