[
https://issues.apache.org/jira/browse/HBASE-19034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl resolved HBASE-19034.
-----------------------------------
Resolution: Won't Fix
Closing as "Won't Fix" as it turns out that the doing this optimization at the
StoreFile (or HFile) Scanner level misses the most important opportunity for
optimization - it's too far down the stack.
> Implement "optimize SEEK to SKIP" in storefile scanner
> ------------------------------------------------------
>
> Key: HBASE-19034
> URL: https://issues.apache.org/jira/browse/HBASE-19034
> Project: HBase
> Issue Type: Sub-task
> Reporter: Guanghao Zhang
> Priority: Major
>
> {code}
> protected boolean trySkipToNextRow(Cell cell) throws IOException {
> Cell nextCell = null;
> do {
> Cell nextIndexedKey = getNextIndexedKey();
> if (nextIndexedKey != null && nextIndexedKey !=
> KeyValueScanner.NO_NEXT_INDEXED_KEY
> && matcher.compareKeyForNextRow(nextIndexedKey, cell) >= 0) {
> this.heap.next();
> ++kvsScanned;
> } else {
> return false;
> }
> } while ((nextCell = this.heap.peek()) != null &&
> CellUtil.matchingRows(cell, nextCell));
> return true;
> }
> {code}
> When SQM return a SEEK_NEXT_ROW, the store scanner will seek to the cell from
> next row. HBASE-13109 optimized the SEEK to SKIP when we can read the cell in
> current loaded block. So it will skip by call heap.next to the cell from next
> row. But the problem is it compare too many times with the nextIndexedKey in
> the while loop. We plan move the compare outside the loop to reduce compare
> times. One problem is the nextIndexedKey maybe changed when call heap.peek,
> because the current storefile scanner was changed. So my proposal is to move
> the "optimize SEEK to SKIP" to storefile scanner. When we call seek for
> storefile scanner, it may real seek or implement seek by several times skip.
> Any suggestions are welcomed. Thanks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
