[
https://issues.apache.org/jira/browse/HIVE-24575?focusedWorklogId=531865&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-531865
]
ASF GitHub Bot logged work on HIVE-24575:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 06/Jan/21 12:39
Start Date: 06/Jan/21 12:39
Worklog Time Spent: 10m
Work Description: dengzhhu653 closed pull request #1822:
URL: https://github.com/apache/hive/pull/1822
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 531865)
Time Spent: 1h (was: 50m)
> VectorGroupByOperator reusing keys can lead to wrong results
> ------------------------------------------------------------
>
> Key: HIVE-24575
> URL: https://issues.apache.org/jira/browse/HIVE-24575
> Project: Hive
> Issue Type: Bug
> Components: Vectorization
> Reporter: Zhihua Deng
> Assignee: Zhihua Deng
> Priority: Major
> Labels: pull-request-available
> Fix For: 4.0.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> A common sql like
> {code:java}
> select category as category, count(distinct maskdid) as uv from
> dwd_internal_inc_d group by category{code}
> can have a wrong result on the trunk, the result of column category can be
> confused and
> aggregate of distinct maskdid is also wrong.
> After some debugging, We find that the problem is caused by wrong
> byteStarts[i] when using it to copy the current keys to the reusable keys:
> [https://github.com/apache/hive/blob/master/ql/src/java/org/apache/hadoop/hive/ql/exec/vector/wrapper/VectorHashKeyWrapperGeneral.java#L351-L362]
> The byteStarts[i] is always 0 due to Arrays.fill(byteStarts, 0); so it copies
> the range from 0 other then the real start index to len of the current keys
> to the reusable keys when clone.byteValues[i].length >= byteValues[i].length
> met, which results to the problem.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
