[
https://issues.apache.org/jira/browse/HBASE-10752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940057#comment-13940057
]
chunhui shen commented on HBASE-10752:
--------------------------------------
bq.I thought one issue was that after a schema change we might not have evicted
all blocks when we scan the next time. So we'll have a scanner that does not
understand the encoding.
It won't happen. When reading, DataBlockEncoding information is recored in
HFile, rather than decided by table schema.
{code}
+ public boolean useEncodedScanner(boolean isCompaction) {
+ if (isCompaction && encoding == DataBlockEncoding.NONE) {
+ return false;
+ }
+ return encoding != DataBlockEncoding.NONE;
+ }
{code}
It seems equal to
{code}
+ public boolean useEncodedScanner(boolean isCompaction) {
+ return encoding != DataBlockEncoding.NONE;
+ }
{code}
> 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)
