hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasanth J (JIRA)" <>
Subject [jira] [Commented] (HIVE-8975) Possible performance regression on bucket_map_join_tez2.q
Date Wed, 26 Nov 2014 22:04:13 GMT


Prasanth J commented on HIVE-8975:

[~jcamachorodriguez] I see what the issue here is. That check (RS after GBY) was used to determine
map-reduce boundary. The map-side GBY has different stats logic as compared to reduce side
Now after the identity projection removal optimization

both GBY[2] and GBY[4] are identified as map-side GBY. I think we need to improve that if
condition to better differentiate map-side and reduce-side GBY. Somewhat better check would
be if RS is contained in upstream operators of GBY then that GBY is reduce side. In the above
case GBY[4] contains RS[3] in its upstreams operators. Any thoughts?

> 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