[
https://issues.apache.org/jira/browse/HBASE-6577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440924#comment-13440924
]
Lars Hofhansl commented on HBASE-6577:
--------------------------------------
J-D and Elliot probably saw this because they're using thrift's
scanOpenWithPrefix which (according to J-D) does this:
{code}
Filter f = new WhileMatchFilter(
new PrefixFilter(getBytes(startAndPrefix)));
{code}
Interestingly TestFilter.testWhileMatchFilterWithFilterRowKey does exactly
that, and it does not fail with this change.
So until I have more data my theory is this: If a filter filters very many rows
in a narrow table, the seeking might actually be far more expensive then the
dump forward iteration.
Also, I noticed that most Filters that filter in filterRowKey are smart enough
to remember their decision and also filter all KV of the row they just
filtered. So maybe this is not even problem. PrefixFilter is an exception,
though.
> RegionScannerImpl.nextRow() should seek to next row
> ---------------------------------------------------
>
> Key: HBASE-6577
> URL: https://issues.apache.org/jira/browse/HBASE-6577
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.96.0, 0.94.2
>
> Attachments: 6577-0.94.txt, 6577.txt, 6577-v2.txt
>
>
> RegionScannerImpl.nextRow() is called when a filter filters the entire row.
> In that case we should seek to the next row rather then iterating over all
> versions of all columns to get there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
