You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Dave Latham (JIRA)" <ji...@apache.org> on 2009/02/08 03:02:59 UTC

[jira] Updated: (HBASE-1190) TableInputFormatBase with row filters scan too far

     [ https://issues.apache.org/jira/browse/HBASE-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dave Latham updated HBASE-1190:
-------------------------------

    Attachment: HBASE-1190.patch

Here's a simple patch, wrapping the StopRowFilter in a WhileMatchRowFilter.  It makes no difference in the output to test, but fixes the performance problem.

> TableInputFormatBase with row filters scan too far 
> ---------------------------------------------------
>
>                 Key: HBASE-1190
>                 URL: https://issues.apache.org/jira/browse/HBASE-1190
>             Project: Hadoop HBase
>          Issue Type: Bug
>          Components: mapred
>    Affects Versions: 0.19.0
>            Reporter: Dave Latham
>            Priority: Minor
>         Attachments: HBASE-1190.patch
>
>
> When TableInputFormatBase has a non-null RowFilterInterface to apply, it creates combines the row filter with a StopRowFilter to get a scanner for each input split.  However, the StopRowFilter never indicates that fitlerAllRemaining is true, so each input split will end up scanning to the end of the table.  (Contrast with HTable.getScanner(byte[][] columns, byte[] starRow, byte[] stopRow, long timestamp) which uses a StopRowFilter wrapped in a WhileMatchRowFilter to ensure that scanning ends at the stop row.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.