hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesus Camacho Rodriguez (JIRA)" <>
Subject [jira] [Commented] (HIVE-8975) Possible performance regression on bucket_map_join_tez2.q
Date Wed, 26 Nov 2014 19:35:12 GMT


Jesus Camacho Rodriguez commented on HIVE-8975:

[~prasanth_j], what do you think?

> Possible performance regression on bucket_map_join_tez2.q
> ---------------------------------------------------------
>                 Key: HIVE-8975
>                 URL:
>             Project: Hive
>          Issue Type: Bug
>          Components: Logical Optimizer, Statistics
>    Affects Versions: 0.15.0
>            Reporter: Jesus Camacho Rodriguez
> After introducing the identity project removal optimization in HIVE-8435, plan in bucket_map_join_tez2.q
that runs on Tez changed to be sub-optimal. In particular, earlier it was doing a map-join
and after HIVE-8435 it changed to a reduce-join.
> The query is the following one:
> {noformat}
> select a.key, b.key from (select distinct key from tab) a join tab b on b.key = a.key
> {noformat}
> The plan before removing the projections is:
> {noformat}
> TS[0]-FIL[16]-SEL[1]-GBY[2]-RS[3]-GBY[4]-SEL[5]-RS[8]-JOIN[11]-SEL[12]-FS[13]
> TS[6]-FIL[17]-RS[10]-JOIN[11]
> {noformat}
> And after removing identity projections:
> {noformat}
> TS[0]-FIL[16]-GBY[2]-RS[3]-GBY[4]-RS[8]-JOIN[11]-SEL[12]-FS[13]
> TS[6]-FIL[17]-RS[10]-JOIN[11]
> {noformat}
> After digging a bit, I realized it is not converting the reduce-join into a map-join
because stats for GBY\[4\] change if SEL\[5\] is removed; thus the optimization does not kick
> The reason for the stats change in the GroupBy operator is in [this line|],
where it is checked whether the GBY is immediately followed by a RS operator or not, and calculate
stats differently depending on it.

This message was sent by Atlassian JIRA

View raw message