[
https://issues.apache.org/jira/browse/HBASE-10018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13919171#comment-13919171
]
Nicolas Liochon commented on HBASE-10018:
-----------------------------------------
I've just committed HBASE-9999. This patch is ready to go.
I see two options:
1) As it is, i.e. full removal of the features, interfaces kept deprecated for
backward compatibility but they do nothing
2) Change the patch to keep the prefetch as an option, deactivated by default.
I've got a small preference for 1), but I don't mind doing 2).
The reason for 2) would be that if there is a performance degradation for some
use cases, we can use the option to to keep us safe.
My reasons for prefering 1) are:
- I remove much more code this way: with 2, I'm unclear about what to do with
the existing code to put/remove a table in the "to prefect" list.
- It's often better to have an optimized code path rather than 2 average.
- an option non activated will become more or less obsolete or buggy very
quickly, so it may not help that much...
As you like guys :-)
> Change the location prefetch
> ----------------------------
>
> Key: HBASE-10018
> URL: https://issues.apache.org/jira/browse/HBASE-10018
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.98.0, 0.96.0
> Reporter: Nicolas Liochon
> Assignee: Nicolas Liochon
> Fix For: 0.99.0
>
> Attachments: 10018.v1.patch, 10018.v2.patch, 10018.v4.patch,
> 10018v3.patch
>
>
> Issues with prefetching are:
> - we do two calls to meta: one for the exact row, one for the prefetch
> - it's done in a lock
> - we take the next 10 regions. Why 10, why the 10 next?
> - is it useful if the table has 100K regions?
> Options are:
> - just remove it
> - replace it with a reverse scan: this would save a call
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
