[
https://issues.apache.org/jira/browse/HIVE-12017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15013907#comment-15013907
]
Jesus Camacho Rodriguez commented on HIVE-12017:
------------------------------------------------
{quote}
-
auto_sortmerge_join_6.q,join42.q,join_star.q,mergejoins_mixed.q,ppd_outer_join5.q,
llap/dynamic_partition_pruning.q : seems like we are generating sub-optimal
plan now.
{quote}
* auto_sortmerge_join_6.q: Join among three tables is not converted to a single
multijoin operator. The reason is that the keys are of different types:
tbl1.key (int), tbl2.key (int), and src.key (String). Calcite type system is
more strict, thus we introduce a {{cast}} (to Double) to join src with the tbl1
on the key column. This {{cast}} operation causes multijoin merge to not be
triggered. It does not seem a problem that we can currently solve;
[~ashutoshc], what do you think?
* join42.q: Transformation into a cartesian product is because they are join
operations on the equality of constant values. Should we consider implementing
the extension to merge cartesian products into single operators?
* join_star.q/mergejoins_mixed.q: This was a good catch. SemanticAnalyzer does
a quite straightforward reordering of join operators (the final goal is to find
more multijoin merge opportunities). When CBO was enabled, this feature was
disabled, as it could lead to reordering the join operations that CBO had
already reordered. However, now we should not exercise this simple reordering
iff Join reordering has been executed in CBO. I have created a new flag
{{disableSemAnalyzerJoinReordering}}, thus this should not be a problem anymore.
* ppd_outer_join5.q: Transformation into a cartesian product is because they
are join operations on the equality of constant values.
* llap/dynamic_partition_pruning.q: I did not see the regression, could you let
me know what you exactly meant for this one?
I am uploading a new patch with the fix for join_star.q/mergejoins_mixed.q to
trigger a new QA run; updating RB too.
> Do not disable CBO by default when number of joins in a query is equal or
> less than 1
> -------------------------------------------------------------------------------------
>
> Key: HIVE-12017
> URL: https://issues.apache.org/jira/browse/HIVE-12017
> Project: Hive
> Issue Type: Improvement
> Components: CBO
> Affects Versions: 2.0.0
> Reporter: Jesus Camacho Rodriguez
> Assignee: Jesus Camacho Rodriguez
> Attachments: HIVE-12017.01.patch, HIVE-12017.02.patch,
> HIVE-12017.03.patch, HIVE-12017.04.patch, HIVE-12017.05.patch,
> HIVE-12017.06.patch, HIVE-12017.07.patch, HIVE-12017.08.patch,
> HIVE-12017.09.patch, HIVE-12017.10.patch, HIVE-12017.11.patch,
> HIVE-12017.12.patch
>
>
> Instead, we could disable some parts of CBO that are not relevant if the
> query contains 1 or 0 joins. Implementation should be able to define easily
> other query patterns for which we might disable some parts of CBO (in case we
> want to do it in the future).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
