cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Eriksson (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7019) Improve tombstone compactions
Date Fri, 05 Feb 2016 12:58:40 GMT


Marcus Eriksson commented on CASSANDRA-7019:

Ok, a few comments (pushed [here|])

* tombstone source iterator is not closed
* we can never bring in data from the tombstone sources into the new compacted sstable (it
brings in the partition level deletion) - this could mess up the timestamps for DTCS for example
* if we are running with "only_purge_repaired_tombstones" and are compacting unrepaired data
we can't drop any tombstones

* did you compare performance when dropping overwritten data?
* we should probably run this for a while on a large data set (unless you did that already?)
* cell level tombstones are not handled, is that for performance reasons? (do we avoid deserializing
the row?)
* should we always enable this for the [single-sstable tombstone compactions|]?

> Improve tombstone compactions
> -----------------------------
>                 Key: CASSANDRA-7019
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Compaction
>            Reporter: Marcus Eriksson
>            Assignee: Branimir Lambov
>              Labels: compaction
>             Fix For: 3.x
> When there are no other compactions to do, we trigger a single-sstable compaction if
there is more than X% droppable tombstones in the sstable.
> In this ticket we should try to include overlapping sstables in those compactions to
be able to actually drop the tombstones. Might only be doable with LCS (with STCS we would
probably end up including all sstables)

This message was sent by Atlassian JIRA

View raw message