[
https://issues.apache.org/jira/browse/HBASE-17958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447057#comment-16447057
]
Duo Zhang commented on HBASE-17958:
-----------------------------------
I still need to say that, never try to revert the patch here. It may lead to
bad performance for some cases comparing to the old implementation, but the old
implementation is wrong.
The alternate solution has already been discussed above. We should move this
optimization to StoreFileScanner. When we need to actually seek the
StoreFileScanner(not lazySeek), we will check which one is faster, a real seek
or a skip.
Thanks.
> Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP
> ----------------------------------------------------------------------------
>
> Key: HBASE-17958
> URL: https://issues.apache.org/jira/browse/HBASE-17958
> Project: HBase
> Issue Type: Bug
> Reporter: Guanghao Zhang
> Assignee: Guanghao Zhang
> Priority: Major
> Fix For: 1.4.0, 2.0.0
>
> Attachments: 0001-add-one-ut-testWithColumnCountGetFilter.patch,
> 17958-add.txt, HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch,
> HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, HBASE-17958-v1.patch,
> HBASE-17958-v2.patch, HBASE-17958-v3.patch, HBASE-17958-v4.patch,
> HBASE-17958-v5.patch, HBASE-17958-v6.patch, HBASE-17958-v7.patch,
> HBASE-17958-v7.patch
>
>
> {code}
> ScanQueryMatcher.MatchCode qcode = matcher.match(cell);
> qcode = optimize(qcode, cell);
> {code}
> The optimize method may change the MatchCode from SEEK_NEXT_COL/SEEK_NEXT_ROW
> to SKIP. But it still pass the next cell to ScanQueryMatcher. It will get
> wrong result when use some filter, etc. ColumnCountGetFilter. It just count
> the columns's number. If pass a same column to this filter, the count result
> will be wrong. So we should avoid passing cell to ScanQueryMatcher when
> optimize SEEK to SKIP.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
