[jira] Updated: (HBASE-980) Undo core of HBASE-975, caching of start and end row

["stack (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HBASE-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stack updated HBASE-980:
------------------------

    Attachment: 980.patch

Commit message:

{code}
M src/test/org/apache/hadoop/hbase/regionserver/TestHStoreFile.java
    Undo tests of features removed.
M  src/java/org/apache/hadoop/hbase/regionserver/HStore.java
    Restore how we used calculate first and final keys.  Also removed
    an unnecessary reset checking if needs split.
M  src/java/org/apache/hadoop/hbase/io/HBaseMapFile.java
    Undo caching of first and last key (HBASE-975)
    (getBloomFilterKey): Move to BloomFilterMapFile.
M  src/java/org/apache/hadoop/hbase/io/HalfMapFileReader.java
    Undo dependence on first and final keys doing halfmapfile.
M  src/java/org/apache/hadoop/hbase/io/BloomFilterMapFile.java
    (getBloomFilterKey): Moved here from HBaseMapFile.
{code}

Patch passes all tests.

> Undo core of HBASE-975, caching of start and end row
> ----------------------------------------------------
>
>                 Key: HBASE-980
>                 URL: https://issues.apache.org/jira/browse/HBASE-980
>             Project: Hadoop HBase
>          Issue Type: Bug
>            Reporter: stack
>             Fix For: 0.19.0
>
>         Attachments: 980.patch
>
>
> Profiling, I learned that the HBASE-975 makes things worse rather than better.  For every Reader opened -- one is opened per store file when we open a region as well as a Reader per file when we compact and then another Reader whenever a Scanner is opened -- the change adds about 4 seeks and at least in the case of compacting and scanning, to no benefit. Even where it is of benefit, when going against HalfMapFiles or when many Store files and we're testing to see if row is in file, it looks like the number of seeks saved are miniscule -- definetly not something that would show up in timings.
> This issue is about undoing the get of first and last key on open of a store file, the heart of HBASE-975 (975 included a bunch of cleanup refactoring. That'll stay).
> Profiling seeks, I did notice that we do an extra seek during a get, a reset that takes us to the start of the file.  Then internally to getClosest, the core of our get, we're also doing a seek to closest index.  Let me try undoing the extra seek and see if it breaks things.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.