[
https://issues.apache.org/jira/browse/HIVE-8225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14162597#comment-14162597
]
Sergey Shelukhin commented on HIVE-8225:
----------------------------------------
Btw, can you try the original simple query
{noformat}
select unionsrc.key FROM (select 'tst1' as key, count(1) as value from src s1)
unionsrc;
{noformat}
Just checking. I thought derived projection we need has to be different (one
should include the dummy count() for it to be accounted for and work, and one
should exclude it because the query doesn't have it); I wonder if this will
work with simple query?
> CBO trunk merge: union11 test fails due to incorrect plan
> ---------------------------------------------------------
>
> Key: HIVE-8225
> URL: https://issues.apache.org/jira/browse/HIVE-8225
> Project: Hive
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Priority: Critical
> Fix For: 0.14.0
>
> Attachments: HIVE-8225.1.patch, HIVE-8225.2.patch, HIVE-8225.3.patch,
> HIVE-8225.4.patch, HIVE-8225.5.patch, HIVE-8225.inprogress.patch,
> HIVE-8225.inprogress.patch, HIVE-8225.patch
>
>
> The result changes to as if the union didn't have count() inside. The issue
> can be fixed by using srcunion.value outside the subquery in count (replace
> count(1) with count(srcunion.value)). Otherwise, it looks like count(1) node
> from union-ed queries is not present in AST at all, which might cause this
> result.
> -Interestingly, adding group by to each query in a union produces completely
> weird result (count(1) is 309 for each key, whereas it should be 1 and the
> "logical" incorrect value if internal count is lost is 500)- Nm, that groups
> by table column called key, which is weird but is what Hive does
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
