[ https://issues.apache.org/jira/browse/HIVE-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13963192#comment-13963192 ]
Sergey Shelukhin commented on HIVE-6430: ---------------------------------------- Tested the patch on real queries. I do see huge memory reduction (modified TPCDS query 72, worst map task goes from 7Gb to ~1.2Gb dump after populating hash tables, I'll need to download the dumps to analyze but it's pretty clear cut); and GC time counter goes down from ~1min total to few seconds, as expected, but I also see huge wall clock time increase (without corresponding CPU time increase it looks like) during processing. I would expect some tradeoff but not as much as I'm seeing... will profile more. > MapJoin hash table has large memory overhead > -------------------------------------------- > > Key: HIVE-6430 > URL: https://issues.apache.org/jira/browse/HIVE-6430 > Project: Hive > Issue Type: Improvement > Reporter: Sergey Shelukhin > Assignee: Sergey Shelukhin > Attachments: HIVE-6430.01.patch, HIVE-6430.02.patch, > HIVE-6430.03.patch, HIVE-6430.04.patch, HIVE-6430.05.patch, > HIVE-6430.06.patch, HIVE-6430.patch > > > Right now, in some queries, I see that storing e.g. 4 ints (2 for key and 2 > for row) can take several hundred bytes, which is ridiculous. I am reducing > the size of MJKey and MJRowContainer in other jiras, but in general we don't > need to have java hash table there. We can either use primitive-friendly > hashtable like the one from HPPC (Apache-licenced), or some variation, to map > primitive keys to single row storage structure without an object per row > (similar to vectorization). -- This message was sent by Atlassian JIRA (v6.2#6252)