Actually each column in a row has the same TTL, so I guess that will not cause fragmentation...? Anyway - any feedback on the questions in my previous mail? ________________________________ From: Nate McCall [n...@thelastpickle.com] Sent: Wednesday, August 21, 2013 8:26 PM To: Cassandra Users Subject: Re: Automatic tombstone compaction
In the context of Yuki's response, if you are using the same key for the cache, then your rows will get increasingly fragmented. On Wed, Aug 21, 2013 at 1:09 PM, <tamas.fold...@thomsonreuters.com<mailto:tamas.fold...@thomsonreuters.com>> wrote: 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<mailto:rc...@eventbrite.com>] Sent: Wednesday, August 21, 2013 7:45 PM To: user@cassandra.apache.org<mailto: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
