[
https://issues.apache.org/jira/browse/HBASE-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221759#comment-13221759
]
Lars Hofhansl commented on HBASE-2038:
--------------------------------------
@Anoop: We can certainly try to expose this at the RegionScanner level.
Although I feel it might actually be harder than you think, as the seeking is
dealt with on a store basis, and we do not want to inhibit the ability to deal
with Stores in parallel in the future.
RegionScanner.seek would have to go through all Stores and for each Store seek
the MemstoreScanner and all StoreFileScanners. Seeking this way across stores
is only valid if we seek on row boundaries (each Store - i.e. column family -
has it's own set of columns, which could even have the same names between
stores).
@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...
> 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
