[
https://issues.apache.org/jira/browse/HIVE-26671?focusedWorklogId=821031&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-821031
]
ASF GitHub Bot logged work on HIVE-26671:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 27/Oct/22 14:34
Start Date: 27/Oct/22 14:34
Worklog Time Spent: 10m
Work Description: scarlin-cloudera commented on code in PR #3706:
URL: https://github.com/apache/hive/pull/3706#discussion_r1006962170
##########
ql/src/java/org/apache/hadoop/hive/ql/optimizer/topnkey/TopNKeyPushdownProcessor.java:
##########
@@ -347,14 +347,12 @@ private void pushdownThroughTopNKey(TopNKeyOperator
topNKey) throws SemanticExce
if (topNKeyDesc.getKeyColumns().size() == commonKeyPrefix.size()) {
// TNK keys are subset of the parent TNK keys
pushdownThroughParent(topNKey);
- if (topNKey.getChildOperators().get(0).getType() ==
OperatorType.TOPNKEY) {
- LOG.debug("Removing {} since child {} supersedes it",
parent.getName(), topNKey.getName());
-
topNKey.getParentOperators().get(0).removeChildAndAdoptItsChildren(topNKey);
- }
+ LOG.debug("Removing {} since child {} supersedes it",
parent.getName(), topNKey.getName());
+
parent.getParentOperators().get(0).removeChildAndAdoptItsChildren(parent);
Review Comment:
I see what you're saying here and that does make sense.
The reason I removed it is because: While I think it's a valid check, is it
necessary?
This code assumes that while we are pushing down, we have the TNK -> TNK in
our subtree, but I'm not sure how that would be possible since the TNK is only
generated above a RS, and a TNK can only be a child (or parent) of a TNK while
it is temporarily going through this pushdown code, and it will always be
resolved by this pushdown code.
But I'm ok with keeping this code there for safety reasons.
Issue Time Tracking
-------------------
Worklog Id: (was: 821031)
Time Spent: 50m (was: 40m)
> Incorrect results for group by/order by/limit query with 2 aggregates
> ---------------------------------------------------------------------
>
> Key: HIVE-26671
> URL: https://issues.apache.org/jira/browse/HIVE-26671
> Project: Hive
> Issue Type: Bug
> Components: Operators
> Reporter: Steve Carlin
> Assignee: Steve Carlin
> Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Grabbed this query from the Impala test suite. It is a query run off of
> tpcds tables, but it's not really super special. You will need a lot of data
> to reproduce this, though.
> select
> l_orderkey,
> min(l_shipdate) as flt,
> count(distinct l_partkey) as cnl
> from lineitem
> group by l_orderkey order by l_orderkey limit 2;
> The issue is with the Top N Key operator optimizer. The Top N Key operator is
> the first operator after the Table Scan. The sort key is on both the
> l_orderkey and l_partkey columns, but this means that the second sort key
> might not be forwarded.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
