[
https://issues.apache.org/jira/browse/HIVE-8395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14163144#comment-14163144
]
Gunther Hagleitner commented on HIVE-8395:
------------------------------------------
[~xuefuz] I've spent a lot of time analyzing results from these runs and I can
tell you that it actually flushed out a lot of issues in the execution
engine(s), because CBO expects any bushy join tree to properly work and that
algebraic rewrites actually produce the same results. Also, it flags any
optimization that has too narrow a set of matching rules. A side effect of this
ticket will be tightening up all these things and feedback to folks adding new
functionality. In general I think this is a huge benefit.
In the case of CBO, the argument of which code path gets exercised is also not
applicable. Unlike vectorization or execution engine, it's additive as I
understand it - it still goes through all the same regular hive code paths
before and after rewriting the AST. CBO is also conservative in when it kicks
in. It makes sure that it has the stats and information it needs before
rewriting the AST. If that's not met, it will just process as usual.
I'm also not sure whether you're saying leave off for 0.14 or trunk. Switching
over for .14 is late in the game (as suggested by the fix version), but turning
on in trunk will give us an entire release cycle to mature which I think is
reasonable, especially given the benefits it can unlock for us.
> CBO: enable by default
> ----------------------
>
> Key: HIVE-8395
> URL: https://issues.apache.org/jira/browse/HIVE-8395
> Project: Hive
> Issue Type: Sub-task
> Components: CBO
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Fix For: 0.14.0
>
> Attachments: HIVE-8395.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
