hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eugene Koifman (JIRA)" <>
Subject [jira] [Commented] (HIVE-17458) VectorizedOrcAcidRowBatchReader doesn't handle 'original' files
Date Sat, 21 Oct 2017 00:31:00 GMT


Eugene Koifman commented on HIVE-17458:

patch 4 adds support for delete events
need a test with multiple stripes, ppd, etc - make sure ids assigned correctly
test make sure compactor assigns them the same way
disable LLAP cache for original read that needs ROW__IDs

> VectorizedOrcAcidRowBatchReader doesn't handle 'original' files
> ---------------------------------------------------------------
>                 Key: HIVE-17458
>                 URL:
>             Project: Hive
>          Issue Type: Improvement
>    Affects Versions: 2.2.0
>            Reporter: Eugene Koifman
>            Assignee: Eugene Koifman
>            Priority: Critical
>         Attachments: HIVE-17458.01.patch, HIVE-17458.02.patch, HIVE-17458.03.patch, HIVE-17458.04.patch
> VectorizedOrcAcidRowBatchReader will not be used for original files.  This will likely
look like a perf regression when converting a table from non-acid to acid until it runs through
a major compaction.
> With Load Data support, if large files are added via Load Data, the read ops will not
vectorize until major compaction.  
> There is no reason why this should be the case.  Just like OrcRawRecordMerger, VectorizedOrcAcidRowBatchReader
can look at the other files in the logical tranche/bucket and calculate the offset for the
RowBatch of the split.  (Presumably getRecordReader().getRowNumber() works the same in vector
> In this case we don't even need OrcSplit.isOriginal() - the reader can infer it from
file path... which in particular simplifies OrcInputFormat.determineSplitStrategies()

This message was sent by Atlassian JIRA

View raw message