It seems like CASSANDRA-3442 might be an effective fix for this issue
assuming that I'm reading it correctly. It sounds like the intent is to
automatically compact SSTables when a certain percent of the columns are
gcable by being deleted or with expired tombstones. Is my understanding
correct?
Would such tables be compacted individually (1-1) or are several eligible
tables selected and compacted using the STCS compaction threshold bounds?
-Bryan
On Thu, Nov 1, 2012 at 9:43 AM, Rob Coli <rc...@palominodb.com> wrote:
> On Thu, Nov 1, 2012 at 1:43 AM, Sylvain Lebresne <sylv...@datastax.com>
> wrote:
> > on all your columns), you may want to force a compaction (using the
> > JMX call forceUserDefinedCompaction()) of that sstable. The goal being
> > to get read of a maximum of outdated tombstones before running the
> > repair (you could also alternatively run a major compaction prior to
> > the repair, but major compactions have a lot of nasty effect so I
> > wouldn't recommend that a priori).
>
> If sstablesplit ("reverse compaction") existed, major compaction would
> be a simple solution to this case. You'd major compact and then split
> your One Giant SSTable With No Tombstones into a number of smaller
> ones. :)
>
> https://issues.apache.org/jira/browse/CASSANDRA-4766
>
> =Rob
>
> --
> =Robert Coli
> AIM>ALK - rc...@palominodb.com
> YAHOO - rcoli.palominob
> SKYPE - rcoli_palominodb
>
