[
https://issues.apache.org/jira/browse/HBASE-8151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607289#comment-13607289
]
Lars Hofhansl commented on HBASE-8151:
--------------------------------------
[~stack] Upon compaction we'd check all the involved HFiles. If all of them
have a MAX_MEMSTORE_TS = 0, we'd create a writer that does not write the
memstoreTS (would need to add includeMemstoreTS(boolean) to writer factory and
make HFileWriteV2.includeMemstoreTS settable at least through the constructor).
That patch for that would be slightly more fragile, have to deal with HFileV1
too.
[[email protected]] Thinking about your comment again. Even though it is not
necessary to set the local memstoreTS variable, it would probably improve
readability.
> 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
>
>
> 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
