hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Shelukhin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HIVE-10068) LLAP: adjust allocation after decompression
Date Tue, 31 Mar 2015 19:04:53 GMT

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

Sergey Shelukhin commented on HIVE-10068:
-----------------------------------------

Actually, this may not be so useful if all ORC files have same size buffers; unless the blocks
are also consolidated at offer time (which is easy, but would mean memory copy), the resulting
returned blocks would all be too fragmented with regard to standard-size allocation (ORC buffer
size)


> LLAP: adjust allocation after decompression
> -------------------------------------------
>
>                 Key: HIVE-10068
>                 URL: https://issues.apache.org/jira/browse/HIVE-10068
>             Project: Hive
>          Issue Type: Sub-task
>            Reporter: Sergey Shelukhin
>
> We don't know decompressed size of a compression buffer in ORC, all we know is the file-level
compression buffer size. For many files, compression buffers can be smaller than that because
of compact encoding, or because compression block ends for other reasons (different streams,
etc. - "present" streams for example are very small).
> BuddyAllocator should be able to accept back parts of the allocated memory (e.g. allocate
256Kb with minimum allocation of 32Kb, decompress 45Kb, return the last 192Kb as 64+128Kb).
For generality (this depends on implementation), we can make an API like "offer", and allocator
can decide to take back however much it can.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message