hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-8151) Small optimization in HFileReaderV2
Date Wed, 20 Mar 2013 05:25:15 GMT

    [ https://issues.apache.org/jira/browse/HBASE-8151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607294#comment-13607294
] 

stack commented on HBASE-8151:
------------------------------

[~lhofhansl] v1 is gone in trunk (smile).  Call it includeMVCC instad of includeMemstoreTS?
 When you say 'does not write the memstoreTS' in the above, you mean, does not set it in KeyValue/Cell?


                
> Small optimization in HFileReaderV2
> -----------------------------------
>
>                 Key: HBASE-8151
>                 URL: https://issues.apache.org/jira/browse/HBASE-8151
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Lars Hofhansl
>         Attachments: 8151-0.94.txt, 8151-0.96.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

Mime
View raw message