[
https://issues.apache.org/jira/browse/HIVE-12631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033970#comment-16033970
]
Sergey Shelukhin commented on HIVE-12631:
-----------------------------------------
In InnerConsumer, where selection is determined, could it use the selected
vector similar to VRB? It could propagate it, and actually set the selected
vector in the file VRB, instead of moving.
Also, should there be a pool of bitsets? They'd probably all be the same size,
or they could be extended.
{noformat}
@Override
public boolean canUseLlapIo() {
return isOriginal;
}
{noformat}
So, it cannot use base files? Are base files only ACID v1?
> LLAP: support ORC ACID tables
> -----------------------------
>
> Key: HIVE-12631
> URL: https://issues.apache.org/jira/browse/HIVE-12631
> Project: Hive
> Issue Type: Bug
> Components: llap, Transactions
> Reporter: Sergey Shelukhin
> Assignee: Teddy Choi
> Attachments: HIVE-12631.1.patch, HIVE-12631.2.patch,
> HIVE-12631.3.patch, HIVE-12631.4.patch, HIVE-12631.5.patch,
> HIVE-12631.6.patch, HIVE-12631.7.patch, HIVE-12631.8.patch, HIVE-12631.8.patch
>
>
> LLAP uses a completely separate read path in ORC to allow for caching and
> parallelization of reads and processing. This path does not support ACID. As
> far as I remember ACID logic is embedded inside ORC format; we need to
> refactor it to be on top of some interface, if practical; or just port it to
> LLAP read path.
> Another consideration is how the logic will work with cache. The cache is
> currently low-level (CB-level in ORC), so we could just use it to read bases
> and deltas (deltas should be cached with higher priority) and merge as usual.
> We could also cache merged representation in future.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
