[
https://issues.apache.org/jira/browse/CASSANDRA-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12834916#action_12834916
]
Stu Hood commented on CASSANDRA-799:
------------------------------------
It seems weird to me that a Memtable removes itself from the list of memtables
in the CFS, which is a symptom of some very tight coupling.
Shouldn't a CFS own a Memtable, give it a handle to an open SSTableWriter to
flush itself, close the writer when it is done, and remove the Memtable? The
easiest way to accomplish this would be to move flushAndSignal to CFS, and
change writeSortedContents to a void on Flushable that takes an open
SSTableWriter. Then you could probably remove the Memtable reference to the CFS
entirely.
> memtable sort is the bottleneck for range query performance
> -----------------------------------------------------------
>
> Key: CASSANDRA-799
> URL: https://issues.apache.org/jira/browse/CASSANDRA-799
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.6
>
> Attachments:
> 0001-refactor-IFlushable-contract-to-push-differences-b-t-M.txt,
> 0002-use-a-sorted-map-for-memtable-contents-to-make-range-q.txt,
> 0003-refactor-to-make-memtablesPendingFlush-a-member-variab.txt,
> 799-unbounded-flushwriter.txt, 799.txt
>
>
> The obvious remedy is to use a sorted map. Unfortunately, keeping the map
> sorted constantly w/ TreeMap was about 30% slower than HashMap + sort back
> when we were doing manual locking. Let's see what the overhead is for
> ConcurrentSkiplistMap vs NBHM.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
