hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (HBASE-980) Undo core of HBASE-975, caching of start and end row
Date Tue, 04 Nov 2008 08:30:44 GMT

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

stack reassigned HBASE-980:

    Assignee: stack

> 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
>            Assignee: 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.

View raw message