cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (Resolved) (JIRA)" <>
Subject [jira] [Resolved] (CASSANDRA-4153) Optimize truncate when snapshots are disabled or keyspace not durable
Date Mon, 16 Apr 2012 20:32:19 GMT


Jonathan Ellis resolved CASSANDRA-4153.

       Resolution: Fixed
    Fix Version/s: 1.1.1
         Reviewer: jbellis
         Assignee: Christian Spriegel

Looks good to me, committed.

(We do want the lock: we're not concerned about writes-in-progress per se (either keeping
them or discarding them is fine), but we definitely want to keep them consistent with their
indexes, and taking out the writeLock here is the only way I can see to do that.)
> Optimize truncate when snapshots are disabled or keyspace not durable
> ---------------------------------------------------------------------
>                 Key: CASSANDRA-4153
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Christian Spriegel
>            Assignee: Christian Spriegel
>            Priority: Minor
>             Fix For: 1.1.1
>         Attachments: OptimizeTruncate_v1.diff
> My goal is to make truncate to be less IO intensive so that my junit tests run faster
(as already explained in CASSANDRA-3710). I think I have now a solution which does not change
too much:
> I created a patch that optimizes three things within truncate:
> - Skip the whole Commitlog.forceNewSegment/discardCompletedSegments, if durable_writes
are disabled for the keyspace.
> - With CASSANDRA-3710 implemented, truncate does not need to flush memtables to disk
when snapshots are disabled.
> - Reduce the sleep interval
> The patch works nicely for me. Applying it and disabling durable_writes/autoSnapshot
increased the speed of my testsuite vastly. I hope I did not overlook something.
> Let me know if my patch needs cleanup. I'd be glad to change it, if it means the patch
will get accepted.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message