[
https://issues.apache.org/jira/browse/HBASE-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808781#comment-13808781
]
Chao Shi commented on HBASE-9000:
---------------------------------
bq. Hah. I just something very similar, but actually in StoreScanner. Not
quite ready, but assumes a seek within a row or to the next row is a near seek,
and the tries next() a few time (I picked 10 as a default).
Did you mean to call next at StoreScanner level? I'm not sure if it is possible
to do this there, as it may not have necessary knowledge about the cost of next
vs. reseek. For example, a next attempt that causes reading another uncached
block from FS is probably worse than do a reseek. I may be wrong as I didn't
read your implementation.
> Linear reseek in Memstore
> -------------------------
>
> Key: HBASE-9000
> URL: https://issues.apache.org/jira/browse/HBASE-9000
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 0.89-fb
> Reporter: Shane Hogan
> Priority: Minor
> Fix For: 0.89-fb
>
> Attachments: hbase-9000-benchmark-program.patch,
> hbase-9000-port-fb.patch
>
>
> This is to address the linear reseek in MemStoreScanner. Currently reseek
> iterates over the kvset and the snapshot linearly by just calling next
> repeatedly. The new solution is to do this linear seek up to a configurable
> maximum amount of times then if the seek is not yet complete fall back to
> logarithmic seek.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
