[
https://issues.apache.org/jira/browse/HBASE-6757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453160#comment-13453160
]
Lars Hofhansl commented on HBASE-6757:
--------------------------------------
The case Jerry mentions is not a problem. "A filterlist of a filterlist of a
filterlist, etc" will work fine.
Also see this code FilterList.filterKeyValue:
{code}
if (operator == Operator.MUST_PASS_ALL) {
if (filter.filterAllRemaining()) {
return ReturnCode.NEXT_ROW;
}
{code}
So it is already possible now that FilterList.filterKeyValue return NEXT_ROW
and hence calling code must deal with it.
Definitely fine for 0.96, but I'm cool with this in 0.94 as well.
> Very inefficient behaviour of scan using FilterList
> ---------------------------------------------------
>
> Key: HBASE-6757
> URL: https://issues.apache.org/jira/browse/HBASE-6757
> Project: HBase
> Issue Type: Improvement
> Components: filters
> Affects Versions: 0.90.6
> Reporter: Jerry Lam
> Attachments: 6757.txt, CopyOfTestColumnPrefixFilter.java,
> DisplayFilter.java
>
>
> The behaviour of scan is very inefficient when using with FilterList.
> The FilterList rewrites the return code from NEXT_ROW to SKIP from a filter
> if Operator.MUST_PASS_ALL is used.
> This happens when using ColumnPrefixFilter. Even though the
> ColumnPrefixFilter indicates to jump to NEXT_ROW because no further match can
> be found, the scan continues to scan all versions of a column in that row and
> all columns of that row because the ReturnCode from ColumnPrefixFilter has
> been rewritten by the FilterList from NEXT_ROW to SKIP.
> This is particularly inefficient when there are many versions in a column
> because the check is performed on all versions of the column instead of just
> by checking the qualifier of the column name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
