[
https://issues.apache.org/jira/browse/HIVE-13617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HIVE-13617:
------------------------------------
Description:
Two approaches - a separate decoding path, into rows instead of VRBs; or
decoding VRBs into rows on a higher level (the original LlapInputFormat). I
think the latter might be better - it's not a hugely important path, and perf
in non-vectorized case is not the best anyway, so it's better to make do with
much less new code and architectural disruption.
Some ORC patches in progress introduce an easy to reuse (or so I hope, anyway)
VRB-to-row conversion, so we should just use that.
was:
Two approaches - a separate decoding path, into rows instead of VRBs; or
decoding VRBs into rows. I think the latter might be better - it's not a hugely
important path, and perf in non-vectorized case is not the best anyway, so it's
better to make do with much less new code and architectural disruption.
Some ORC patches in progress introduce an easy to reuse (or so I hope, anyway)
VRB-to-row conversion, so we should just use that.
> LLAP: support non-vectorized execution in IO
> --------------------------------------------
>
> Key: HIVE-13617
> URL: https://issues.apache.org/jira/browse/HIVE-13617
> Project: Hive
> Issue Type: Bug
> Reporter: Sergey Shelukhin
>
> Two approaches - a separate decoding path, into rows instead of VRBs; or
> decoding VRBs into rows on a higher level (the original LlapInputFormat). I
> think the latter might be better - it's not a hugely important path, and perf
> in non-vectorized case is not the best anyway, so it's better to make do with
> much less new code and architectural disruption.
> Some ORC patches in progress introduce an easy to reuse (or so I hope,
> anyway) VRB-to-row conversion, so we should just use that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
