hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Shelukhin (JIRA)" <>
Subject [jira] [Updated] (HIVE-6429) MapJoinKey has large memory overhead in typical cases
Date Fri, 28 Feb 2014 03:17:19 GMT


Sergey Shelukhin updated HIVE-6429:

    Attachment: HIVE-6429.08.patch

after some more discussion, we decided to rewrite once again using LazyBinarySerde. I preserved
some refactoring done to BinarySortableSerde.

So here's a 3rd way to do this. There are many more untapped serde-s out there... :)

I've ran a few tests that failed previously and a couple Tez tests, they all pass. I will
run all tez tests now, and all tests overnight if I don't forget

> MapJoinKey has large memory overhead in typical cases
> -----------------------------------------------------
>                 Key: HIVE-6429
>                 URL:
>             Project: Hive
>          Issue Type: Improvement
>            Reporter: Sergey Shelukhin
>            Assignee: Sergey Shelukhin
>         Attachments: HIVE-6429.01.patch, HIVE-6429.02.patch, HIVE-6429.03.patch, HIVE-6429.04.patch,
HIVE-6429.05.patch, HIVE-6429.06.patch, HIVE-6429.07.patch, HIVE-6429.08.patch, HIVE-6429.WIP.patch,
> The only thing that MJK really needs it hashCode and equals (well, and construction),
so there's no need to have array of writables in there. Assuming all the keys for a table
have the same structure, for the common case where keys are primitive types, we can store
something like a byte array combination of keys to reduce the memory usage. Will probably
speed up compares too.

This message was sent by Atlassian JIRA

View raw message