[
https://issues.apache.org/jira/browse/HIVE-9555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14366584#comment-14366584
]
Gopal V commented on HIVE-9555:
-------------------------------
[~sershe]: Review 1-pass done, I've understood what you're trying to do & how
it is being done.
StringTreeReader is effectively exposed towards llap-server impls to override
seeks through a cache.
This might not be the best way to mix-in the cache-encoded and raw data readers
for each format chunk, so let me investigate a bit further on how the exposure
can be limited only what we need.
> assorted ORC refactorings for LLAP on trunk
> -------------------------------------------
>
> Key: HIVE-9555
> URL: https://issues.apache.org/jira/browse/HIVE-9555
> Project: Hive
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Attachments: HIVE-9555.01.patch, HIVE-9555.02.patch,
> HIVE-9555.03.patch, HIVE-9555.04.patch, HIVE-9555.05.patch,
> HIVE-9555.06.patch, HIVE-9555.07.patch, HIVE-9555.patch
>
>
> To minimize conflicts and given that ORC is being developed rapidly on trunk,
> I would like to refactor some parts of ORC "in advance" based on the changes
> in LLAP branch. Mostly it concerns making parts of ORC code (esp. SARG, but
> also some internal methods) more modular and easier to use from alternative
> codepaths. There's also significant change to how data reading is handled -
> BufferChunk inherits from DiskRange; the reader receives a list of
> DiskRange-s (as before), but instead of making a list of buffer chunks it
> replaces ranges with buffer chunks in the original (linked) list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
