cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-799) memtable sort is the bottleneck for range query performance
Date Wed, 17 Feb 2010 19:08:28 GMT


Jonathan Ellis commented on CASSANDRA-799:

stu, there is tension here between the goals of "decouple" and "encapsulate" -- either CFS
cheats and does part of the work that should be in MT/BMT, special casing as necessary, the
way we had it before, or we let MT r/m itself from the pending list.

since MT is already reaching in to CFS in places (this is far from the only place, check again
-- the way it was before it was looking up CFS by table/cf name, which isn't really decoupled,
it's just sloppy) I think I prefer the latter since then at least we are being consistent.

> memtable sort is the bottleneck for range query performance
> -----------------------------------------------------------
>                 Key: CASSANDRA-799
>                 URL:
>             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.

View raw message