You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Seonggon Namgung (Jira)" <ji...@apache.org> on 2025/03/28 11:08:00 UTC
[jira] [Created] (HIVE-28855) VectorGroupByOperator computes maxHashTblMemory using incorrect configuration.
Seonggon Namgung created HIVE-28855:
---------------------------------------
Summary: VectorGroupByOperator computes maxHashTblMemory using incorrect configuration.
Key: HIVE-28855
URL: https://issues.apache.org/jira/browse/HIVE-28855
Project: Hive
Issue Type: Bug
Reporter: Seonggon Namgung
Assignee: Seonggon Namgung
The VectorGroupByOperator computes maxHashTblMemory using an incorrect configuration parameter, leading to inconsistencies in HashTable memory management between GroupByOperator and VectorGroupByOperator.
There are two configuration properties relevant to GroupBy HashTable memory management in Hive: hive.map.aggr.hash.force.flush.memory.threshold and hive.map.aggr.hash.percentmemory.
GroupByOperator flushes the HashTable when:
(1) The total memory usage exceeds the force flush threshold (hive.map.aggr.hash.force.flush.memory.threshold).
(2) The estimated size of the hash table exceeds maxHashTblMemory.
VectorGroupByOperator follows a slightly different approach. It flushes the HashTable when
(1) GC happened after the last flush.
(2) The estimated size of the hash table exceeds maxHashTblMemory.
The problem is that GroupByOperator computes maxHashTblMemory using hive.map.aggr.hash.percentmemory, while VectorGroupByOperator computes it using hive.map.aggr.hash.force.flush.memory.threshold. As GroupByOperator does, VectorGroupByOperator should use hive.map.aggr.hash.percentmemory when computing maxHashTblMemory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)