[
https://issues.apache.org/jira/browse/HBASE-10752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939762#comment-13939762
]
Lars Hofhansl commented on HBASE-10752:
---------------------------------------
Honestly I am not sure. I find hard to think through all the implications here.
As for the original patch, we move encoding from the key, but then we just seem
to pass it around separately everywhere a cache key goes. Is there a way to fix
cache key and cache config to do the right thing? Or would that defeat the
purpose of the original issues (namely that we can think of a CompoundScanner,
etc).
> Port HBASE-10270 'Remove DataBlockEncoding from BlockCacheKey' to trunk
> -----------------------------------------------------------------------
>
> Key: HBASE-10752
> URL: https://issues.apache.org/jira/browse/HBASE-10752
> Project: HBase
> Issue Type: Improvement
> Reporter: Ted Yu
> Assignee: Ted Yu
> Priority: Minor
> Fix For: 0.99.0
>
> Attachments: 10752-v1.txt, 10752-v2.txt, 10752-v3.txt, 10752-v4.txt
>
>
> The JIRA removes the block encoding from the key and forces the caller of
> HFileReaderV2.readBlock() to specify the expected BlockType as well as the
> expected DataBlockEncoding when these matter. This allows for a decision on
> either of these at read time instead of cache time, puts responsibility where
> appropriate, fixes some cache misses when using the scan preloading (which
> does a read without knowing the type or encoding), allows for the
> BlockCacheKey to be re-used by the L2 BucketCache and sets us up for a future
> CompoundScannerV2 which can read both un-encoded and encoded data blocks.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
