incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <tamas.fold...@thomsonreuters.com>
Subject RE: Automatic tombstone compaction
Date Wed, 21 Aug 2013 18:09:12 GMT
Well, these tables are somewhat similar to a 'cache' - we insert rows, then leave them for
a week using TTL (usually untouched, read only), and then we need to compact them away. If
I understand correctly, they should not be affected by the below issue...
The question is rather if the setup is correct - i.e the ALTER statement I quoted below?

Also, I the docs were not clear to me - is automatic tombstone compaction 'on' by default
(even if the sstables have been migrated from an older version)? Or do I need to alter the
columnfamily (like I did) to turn it on?

________________________________
From: Robert Coli [rcoli@eventbrite.com]
Sent: Wednesday, August 21, 2013 7:45 PM
To: user@cassandra.apache.org
Subject: Re: Automatic tombstone compaction

On Wed, Aug 21, 2013 at 8:23 AM, Yuki Morishita <mor.yuki@gmail.com<mailto:mor.yuki@gmail.com>>
wrote:
If there are rows with the same key in other SSTables, that rows won't
be deleted.
Tombstone compaction make guess if it can actually drop "safely" by
scanning overlap with other SSTables.

Background @ :

https://issues.apache.org/jira/browse/CASSANDRA-1074

=Rob


Mime
View raw message