[
https://issues.apache.org/jira/browse/HBASE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082435#comment-13082435
]
nkeywal commented on HBASE-1938:
--------------------------------
Yes, I believe Andy's issue was cause by:
- the improvement was actually not used in the test case
- may be the point in the getLower implementation mentionned above.
I fixed both points, so I believe it can be integrated.
I also added the synchronized because it was strange to have all other public
methods synchronized except this one, but I didn't check if some test case were
actually calling them in //. I will have a look at HBASE-3855 and come back to
you if I find something.
> Make in-memory table scanning faster
> ------------------------------------
>
> Key: HBASE-1938
> URL: https://issues.apache.org/jira/browse/HBASE-1938
> Project: HBase
> Issue Type: Improvement
> Components: performance
> Reporter: stack
> Assignee: nkeywal
> Priority: Blocker
> Fix For: 0.90.4, 0.92.0
>
> Attachments: 20110726_1938_KeyValueSkipListSet.patch,
> 20110726_1938_MemStore.patch, 20110726_1938_MemStoreScanPerformance.java,
> 20110802_MemStore.patch, MemStoreScanPerformance.java,
> MemStoreScanPerformance.java, MemStoreScanPerformance.java,
> caching-keylength-in-kv.patch, test.patch
>
>
> This issue is about profiling hbase to see if I can make hbase scans run
> faster when all is up in memory. Talking to some users, they are seeing
> about 1/4 million rows a second. It should be able to go faster than this
> (Scanning an array of objects, they can do about 4-5x this).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
