hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Duo Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17958) Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP
Date Wed, 26 Apr 2017 00:47:04 GMT

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

Duo Zhang commented on HBASE-17958:
-----------------------------------

The idea is good, and converting seek to skip is a common optimization.

The 'bad practice' here is the way we implement it. If the MatchCode is SEEK_NEXT_ROW or SEEK_NEXT_COL,
no matter how you done the seek, either by a real seek or a sequence of skips, you should
stop passing the cell in the same row or same column to the SQM, otherwise you should change
the MatchCode to TRY_SEEK_NEXT_ROW and TRY_SEEK_NEXT_COL. It is really confusing.

That's my point.

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
>
> {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
(v6.3.15#6346)

Mime
View raw message