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

Anoop Sam John commented on HBASE-2038:
---------------------------------------

{quote}
@HBASE-5521: I started working on that, but I am starting to question the 
usefulness.
A filter is per KeyValue (at least the method that allows for seeking). So, 
many KeyValues flow through the Filter for a single row, and the filter needs 
to seek separately for each ColumnFamily (as explained above and on the mailing 
list).
So the gain from this would be fairly minimal (which I guess is why we do not 
have this).
For example a row with many column would need to issue many INCLUDE's and only 
for the last KeyVakue (and how would it know it's the last?) issue 
INCLUDE_AND_SEEK..
{quote}

Lars,   I was also thinking on this yesterday after seeing the patch. I wanted 
to give a test case try run before commenting :) 

Regarding you 1st comment, In our above discussion scenario of seek() we need a 
row boundary seek.. Yes all the stores ( memstore and all store files in that 
store) need to get seeked to needed point. Let me see more on this on Monday. 
we had done small changes and tested this once. I mean we were able to seek to 
row boundaries.

Thanks a lot Lars for your work and suggestion

@Ram: Yes we can file a Jira for co processor support for next( int nbrows)?

                
> Coprocessors: Region level indexing
> -----------------------------------
>
>                 Key: HBASE-2038
>                 URL: https://issues.apache.org/jira/browse/HBASE-2038
>             Project: HBase
>          Issue Type: New Feature
>          Components: coprocessors
>            Reporter: Andrew Purtell
>            Priority: Minor
>
> HBASE-2037 is a good candidate to be done as coprocessor. It also serve as a 
> good goalpost for coprocessor environment design -- there should be enough of 
> it so region level indexing can be reimplemented as a coprocessor without any 
> loss of functionality. 

--
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

        

Reply via email to