[
https://issues.apache.org/jira/browse/HIVE-5186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13757010#comment-13757010
]
Yin Huai commented on HIVE-5186:
--------------------------------
Right, I am removing cases associated with the pattern "JOIN%.*%RS%".
Here are my reasons.
1. Seems JoinReducerProc will kick in when hive.auto.convert.join=false and
hive.auto.convert.join.noconditionaltask=false. Because of these conditions, I
thought maybe it is hard to trigger this part of code in practice.
2. For some cases, I am not sure if we can generate executable plan when both
JoinReducerProc and Correlation Optimizer fire.
For example,
{code}
JOIN3
/ \
/ \
/ \
GBY1 GBY2
| |
| |
JOIN1 JOIN2
{code}
If all of these five operators share the same key, JoinReducerProc will drop
the RS between JOIN1 and GBY1, and drop the RS between JOIN2 and GBY2. Then,
Correlation Optimizer will try to drop the RSs associated with JOIN3. Since
there is no Mux between JOIN1 and GBY1, and between JOIN2 and GBY2, I am not
sure if the plan is executable. But I have not tried this case. Will give it a
try and post what I find.
> Remove JoinReducerProc from ReduceSinkDeDuplication
> ---------------------------------------------------
>
> Key: HIVE-5186
> URL: https://issues.apache.org/jira/browse/HIVE-5186
> Project: Hive
> Issue Type: Improvement
> Reporter: Yin Huai
> Assignee: Yin Huai
> Priority: Minor
> Attachments: HIVE-5186.1.patch.txt
>
>
> Correlation Optimizer will take care patterns involving JoinOperator. We can
> remove JoinReducerProc from ReduceSinkDeDuplication.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
