hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasanth Jayachandran (JIRA)" <>
Subject [jira] [Updated] (HIVE-8975) Possible performance regression on bucket_map_join_tez2.q
Date Wed, 03 Dec 2014 01:42:13 GMT


Prasanth Jayachandran updated HIVE-8975:
    Attachment: HIVE-8975.1.patch

I ran few different combinations of group by queries and found that GBY in reduce side always
has mode MERGEPARTIAL. So I believe its safe to assume reduce side GBY will always has mergepartial
mode. I don't really fully understand other GBY modes (like PARTIAL1, PARTIAL2, PARTIALS,
 [~ashutoshc] Can you correct me if my understanding is wrong? Also can you take a look at
this minor patch?

> 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
>            Assignee: Prasanth Jayachandran
>         Attachments: HIVE-8975.1.patch
> 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