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> 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] > *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>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 > >
