hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-13109) Make better SEEK vs SKIP decisions during scanning
Date Wed, 04 Mar 2015 01:54:05 GMT

    [ https://issues.apache.org/jira/browse/HBASE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14346217#comment-14346217
] 

Lars Hofhansl edited comment on HBASE-13109 at 3/4/15 1:53 AM:
---------------------------------------------------------------

Same, but with each column in its own CF (in this case Phoenix does not use its WildcardTracker
+ Filter optimization)

6CF case:
|| ||q1||q2||
|w/o patch|15.3|15.5|
|w/ patch|9.14|9.19|

Any objection committing this to all branches?
([~stack], [~apurtell], [~ram_krish]?)

[~giacomotaylor], FYI (we can probably remove the ColumnProjectionFilter optimization when
this is in)


was (Author: lhofhansl):
Same, but with each column in its own CF (in this case Phoenix does not use its WildcardTracker
+ Filter optimization)

6CF case:
|| ||q1||q2||
|w/o patch|15.3|15.5|
|w/ patch|9.14|9.19|

Any objection committing this to all branches.

[~giacomotaylor], FYI (we can probably remove the ColumnProjectionFilter optimization when
this is in)

> Make better SEEK vs SKIP decisions during scanning
> --------------------------------------------------
>
>                 Key: HBASE-13109
>                 URL: https://issues.apache.org/jira/browse/HBASE-13109
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>            Priority: Minor
>         Attachments: 13109-0.98-v4.txt, 13109-trunk-v2.txt, 13109-trunk-v3.txt, 13109-trunk-v4.txt,
13109-trunk-v5.txt, 13109-trunk.txt, nextIndexKVChange_new.patch
>
>
> I'm re-purposing this issue to add a heuristic as to when to SEEK and when to SKIP Cells.
This has come up in various issues, and I think I have a way to finally fix this now. HBASE-9778,
HBASE-12311, and friends are related.
> --- Old description ---
> This is a continuation of HBASE-9778.
> We've seen a scenario of a very slow scan over a region using a timerange that happens
to fall after the ts of any Cell in the region.
> Turns out we spend a lot of time seeking.
> Tested with a 5 column table, and the scan is 5x faster when the timerange falls before
all Cells' ts.
> We can use the lookahead hint introduced in HBASE-9778 to do opportunistic SKIPing before
we actually seek.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message