[
https://issues.apache.org/jira/browse/HBASE-10625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914360#comment-13914360
]
Anoop Sam John edited comment on HBASE-10625 at 2/27/14 10:33 AM:
------------------------------------------------------------------
bq.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.
Sounds reasonable.
bq.(I tested with rows of 5 short KVs selected the 2nd and or 4th column)
Test with adjacent cols like 4th and 5th (?)
bq.The Findbugs warnings seem wrong, there are none for the file I modified
Yes. 2 new findbugs because of HBASE-10598 commit. The findbugs seems not
relevant also. So the current findbugs count to be updated accordingly?
was (Author: anoop.hbase):
bq.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.
Sounds reasonable.
bq.(I tested with rows of 5 short KVs selected the 2nd and or 4th column)
Test with adjacent cols like 4th and 5th (?)
bq.The Findbugs warnings seem wrong, there are none for the file I modified
Yes. 2 new findbugs because of HBASE-10598 commit. The findbugs seems not
relevant also. Still we have Writable
> 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.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.1.5#6160)
