Mailing-List: contact issues-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hive.apache.org
Date: Tue, 14 Mar 2017 00:25:41 +0000 (UTC)
From: "Sergey Shelukhin (JIRA)" <jira@apache.org>
To: issues@hive.apache.org
Message-ID: <JIRA.13049448.1489018973000.8844.1489451141744@Atlassian.JIRA>
In-Reply-To: <JIRA.13049448.1489018973000@Atlassian.JIRA>
References: <JIRA.13049448.1489018973000@Atlassian.JIRA> <JIRA.13049448.1489018973228@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HIVE-16151) BytesBytesHashTable allocates large
 arrays
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 14 Mar 2017 00:25:46 -0000


    [ https://issues.apache.org/jira/browse/HIVE-16151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15923302#comment-15923302 ] 

Sergey Shelukhin commented on HIVE-16151:
-----------------------------------------

[~gopalv] can you review this at some point? thanks
[~mmccline] mentioned that you may not like this approach ;)

> BytesBytesHashTable allocates large arrays
> ------------------------------------------
>
>                 Key: HIVE-16151
>                 URL: https://issues.apache.org/jira/browse/HIVE-16151
>             Project: Hive
>          Issue Type: Bug
>            Reporter: Prasanth Jayachandran
>            Assignee: Sergey Shelukhin
>         Attachments: HIVE-16151.patch
>
>
> These arrays cause GC pressure and also impose key count limitations on the table. Wrt the latter, we won't be able to get rid of it without a 64-bit hash function, but for now we can get rid of the former. If we need the latter we'd add murmur64 and probably account for it differently for resize (we don't want to blow up the hashtable by 4 bytes/key in the common case where #of keys is less than ~1.5B :))


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)