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 [rc...@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.y...@gmail.com<mailto:mor.y...@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
