[
https://issues.apache.org/jira/browse/HIVE-13750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290128#comment-15290128
]
Ashutosh Chauhan commented on HIVE-13750:
-----------------------------------------
Compiler side changes look good. I left some comments on RB.
But I wonder if this breaks any assumption for FS operator about order in which
it expects rows to arrive to be written out. Since earlier all rows for a
corresponding partition in a Reducer needs to come sorted in a single batch,
but now they may come sorted but in multiple batches. [~prasanth_j] Can you
also please take a look at patch and comment?
> Avoid additional shuffle stage created by Sorted Dynamic Partition Optimizer
> when possible
> ------------------------------------------------------------------------------------------
>
> Key: HIVE-13750
> URL: https://issues.apache.org/jira/browse/HIVE-13750
> Project: Hive
> Issue Type: Improvement
> Components: Physical Optimizer
> Affects Versions: 2.1.0
> Reporter: Jesus Camacho Rodriguez
> Assignee: Jesus Camacho Rodriguez
> Attachments: HIVE-13750.01.patch, HIVE-13750.02.patch,
> HIVE-13750.patch, HIVE-13750.patch
>
>
> Extend ReduceDedup to remove additional shuffle stage created by sorted
> dynamic partition optimizer when possible, thus avoiding unnecessary work.
> By [~ashutoshc]:
> {quote}
> Currently, if config is on Sorted Dynamic Partition Optimizer (SDPO)
> unconditionally adds an extra shuffle stage. If sort columns of previous
> shuffle and partitioning columns of table match, reduce sink deduplication
> optimizer removes extra shuffle stage, thus bringing down overhead to zero.
> However, if they don’t match, we end up doing extra shuffle. This can be
> improved since we can add table partition columns as a sort columns on
> earlier shuffle and avoid this extra shuffle. This ensures that in cases
> query already has a shuffle stage, we are not shuffling data again.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
