[
https://issues.apache.org/jira/browse/HBASE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14362121#comment-14362121
]
Andrew Purtell commented on HBASE-13109:
----------------------------------------
[~giacomotaylor] JavaACC says the changes have no binary compat impact with
already compiled code. I don't see how previous releases of Phoenix are broken.
I think that states the problem too strongly. It is true that recompilation
will be problematic without accommodation (see above) or local patching, but
that's not the same thing as broken, right?
> Make better SEEK vs SKIP decisions during scanning
> --------------------------------------------------
>
> Key: HBASE-13109
> URL: https://issues.apache.org/jira/browse/HBASE-13109
> Project: HBase
> Issue Type: Improvement
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
>
> 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)
