[
https://issues.apache.org/jira/browse/HBASE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13649001#comment-13649001
]
Lars Hofhansl commented on HBASE-8362:
--------------------------------------
It's on my (long'ish) list of things to do.
It is not 100% clear that we would see a large improvement from this.
If the Gets in a batch a far apart (in terms of blocks) reseek won't buy much;
if on the other hand there is a high probability that the Gets end up on the
same block we'd expect to see an improvement.
I am not saying it should not be done, just that I do not think this should be
generally enabled, but be at the discretion of the caller. I.e. a new API.
If ROW bloomfilters would work with scans this might be a different story.
Another consideration could be a new scanner API (something like reseekExact or
something), which would attempt to reseek to an exact position and indicate
whether than succeeded or not.
> Possible MultiGet optimization
> ------------------------------
>
> Key: HBASE-8362
> URL: https://issues.apache.org/jira/browse/HBASE-8362
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
>
> Currently MultiGets are executed on a RegionServer in a single thread in a
> loop that handles each Get separately (opening a scanner, seeking, etc).
> It seems we could optimize this (per region at least) by opening a single
> scanner and issue a reseek for each Get that was requested.
> I have not tested this yet and no patch, but I would like to solicit feedback
> on this idea.
--
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
