hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-2038) Coprocessors: Region level indexing
Date Sun, 04 Mar 2012 05:48:09 GMT

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

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

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


View raw message