[
https://issues.apache.org/jira/browse/HBASE-10625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-10625:
----------------------------------
Attachment: 10625-0.94-experimental.txt
Another experimental patch. This one gives results.
The observation is that we do not need to check the top key during each
iteration of the generalizedSeek. Either we exhausted the current scanner, or
we're now positioned correctly.
Will make a trunk patch to get a test run.
> Remove unnecessary key compare from AbstractScannerV2.reseekTo
> --------------------------------------------------------------
>
> Key: HBASE-10625
> URL: https://issues.apache.org/jira/browse/HBASE-10625
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Attachments: 10625-0.94-experimental.txt, 10625-0.94.txt,
> 10625-trunk.txt
>
>
> In reseekTo we find this
> {code}
> ...
> compared = compareKey(reader.getComparator(), key, offset, length);
> if (compared < 1) {
> // If the required key is less than or equal to current key, then
> // don't do anything.
> return compared;
> } else {
> ...
> return loadBlockAndSeekToKey(this.block, this.nextIndexedKey,
> false, key, offset, length, false);
> ...
> {code}
> loadBlockAndSeekToKey already does the right thing when a we pass a key that
> sorts before the current key. It's less efficient than this early check, but
> in the vast (all?) cases we pass forward keys (as required by the reseek
> contract). We're optimizing the wrong thing.
> Scanning with the ExplicitColumnTracker is 20-30% faster.
> (I tested with rows of 5 short KVs selected the 2nd and or 4th column)
> I propose simply removing that check.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
