[ 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)