[
https://issues.apache.org/jira/browse/HIVE-8225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14145804#comment-14145804
]
Sergey Shelukhin commented on HIVE-8225:
----------------------------------------
I added the aggregation to plan before AST transformation (the rule-based
addition doesn't work because the type of the node is different when you add:
{noformat}
Cannot add expression of different type to set:
set type is RecordType() NOT NULL
expression type is RecordType(BIGINT NOT NULL $f0) NOT NULL
set is rel#50:HiveAggregateRel.HIVE.[](child=HepRelVertex#49,group={})
{noformat}
That doesn't appear to do anything (presumably because there's no select
expression in projection rel to put the aggregate into).
Probably the aggregate needs to be added back to inner of the AST, or another
intermediate projection needs to be added. I will continue looking tomorrow.
> 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
>
> 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)
