[
https://issues.apache.org/jira/browse/HBASE-8151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609734#comment-13609734
]
Hudson commented on HBASE-8151:
-------------------------------
Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #458 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/458/])
HBASE-8151 Decode memstoreTS in HFileReaderV2 only when necessary (Revision
1459433)
Result = FAILURE
larsh :
Files :
*
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV2.java
> Decode memstoreTS in HFileReaderV2 only when necessary
> ------------------------------------------------------
>
> Key: HBASE-8151
> URL: https://issues.apache.org/jira/browse/HBASE-8151
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.95.0, 0.98.0, 0.94.7
>
> Attachments: 8151-0.94.txt, 8151-0.94-v2.txt, 8151-0.96.txt,
> 8151-0.96-v2.txt, 8151-0.96-v3.txt
>
>
> HFiles V2 store the memstoreTS of each KV.
> In many cases all the KVs in an HFile will have a memstoreTS of 0 (that is
> the case when at the time the HFile was written there are no KVs that were
> created after the oldest still active scanner - which is frequently the case).
> In that case we:
> # do not need to decode the memstoreTS (a vlong), since we know its value is
> 0 and its length is 1 byte.
> # when we compact HFiles and all of the involved files have only KVs with
> memstoreTS = 0 we know ahead of time that all KVs meet this condition and we
> do not need to store the memstoreTS in the new HFile.
> This issue will cover the first part. The performance improvement will be
> modest as it is fairly cheap to decode vlongs of size 1.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
