hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17958) Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP
Date Thu, 19 Oct 2017 04:51:00 GMT

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

Lars Hofhansl commented on HBASE-17958:
---------------------------------------

bq. sad thing is that, the indexed key could be changed if you call heap.next...

That is true, but it only means we're losing out on another chance for this optimization.
The next indexed key will never go backwards, right? I think losing that is acceptable compared
to the extra compare for each single KV. Doing the identity comparison that you mention is
also a good idea.

Anyway, doing this in StoreFileScanner is better I think.

Thanks for humoring me here :)

> 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
>             Fix For: 2.0.0, 1.4.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
(v6.4.14#64029)

Mime
View raw message