[
https://issues.apache.org/jira/browse/HIVE-24234?focusedWorklogId=496334&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-496334
]
ASF GitHub Bot logged work on HIVE-24234:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 07/Oct/20 06:39
Start Date: 07/Oct/20 06:39
Worklog Time Spent: 10m
Work Description: rbalamohan opened a new pull request #1560:
URL: https://github.com/apache/hive/pull/1560
https://issues.apache.org/jira/browse/HIVE-24234
Queries with grouping sets process input records multiple times and
increases significantly the number hash aggregation lookup operations. When
there is not significant reduction with aggregation, it becomes memory
intensive and adds up to JVM mem pressure.
Earlier, due to minor bug, it wasn't switching over to hash mode. This has
been fixed in the current patch and also takes care of the situation, when
grouping sets are not very effective in reduction.
Tried out Q67 in TPCDS in internal cluster which shows significant
improvement with this.
For standalone tests, TestVectorGroupByOperator covers this.
----------------------------------------------------------------
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: 496334)
Remaining Estimate: 0h
Time Spent: 10m
> Improve checkHashModeEfficiency in VectorGroupByOperator
> --------------------------------------------------------
>
> Key: HIVE-24234
> URL: https://issues.apache.org/jira/browse/HIVE-24234
> Project: Hive
> Issue Type: Improvement
> Reporter: Rajesh Balamohan
> Priority: Major
> Attachments: HIVE-24234.wip.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, {{VectorGroupByOperator::checkHashModeEfficiency}} compares the
> number of entries with the number input records that have been processed. For
> grouping sets, it accounts for grouping set length as well.
> Issue is that, the condition becomes invalid after processing large number of
> input records. This prevents the system from switching over to streaming
> mode.
> e.g Assume 500,000 input records processed, with 9 grouping sets, with
> 100,000 entries in hashtable. Hashtable would never cross 4,500,0000 entries
> as the max size itself is 1M by default.
> It would be good to compare the input records (adjusted for grouping sets)
> with number of output records (along with size of hashtable size) to
> determine hashing or streaming mode.
> E.g Q67.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
