[
https://issues.apache.org/jira/browse/HIVE-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260160#comment-16260160
]
Eugene Koifman commented on HIVE-16669:
---------------------------------------
consider: delta_26_29 and delete_delta_29_29 - current implementation of
getAcidState() will consider delete_delta_29_29 obsolete. Given current
implementation of write path/compaction this can't happen but if deleta and
delete_delta ranges can evolve independently it could. Perhaps getAcidSate()
should keep 2 'working' collections and filter each separately.
> Fine tune Compaction to take advantage of Acid 2.0
> --------------------------------------------------
>
> Key: HIVE-16669
> URL: https://issues.apache.org/jira/browse/HIVE-16669
> Project: Hive
> Issue Type: Bug
> Components: Transactions
> Reporter: Eugene Koifman
> Assignee: Eugene Koifman
> Priority: Critical
> Attachments: HIVE-16669.wip.patch
>
>
> * There is little point using 2.0 vectorized reader since there is no
> operator pipeline in compaction
> * If minor compaction just concats delete_delta files together, then the 2
> stage compaction should always ensure that we have a limited number of Orc
> readers to do the merging and current OrcRawRecordMerger should be fine
> * ...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
