re: the tombstone sstables being read-only inputs to compaction, there
would be one case the non-tombstone sstables would input to the compaction
of the row tombstones: when the row no longer exists in any of the data
sstables with respect to the row tombstone timestamp.
There may be other opportu
Worth a JIRA, yes
On Wed, Feb 14, 2018 at 9:45 AM, Carl Mueller
wrote:
> So is this at least a decent candidate for a feature request ticket?
>
>
> On Tue, Feb 13, 2018 at 8:09 PM, Carl Mueller <
> carl.muel...@smartthings.com>
> wrote:
>
> > I'm particularly interested in getting the tombstone
So is this at least a decent candidate for a feature request ticket?
On Tue, Feb 13, 2018 at 8:09 PM, Carl Mueller
wrote:
> I'm particularly interested in getting the tombstones to "promote" up the
> levels of LCS more quickly. Currently they get attached at the low level
> and don't propagate
I'm particularly interested in getting the tombstones to "promote" up the
levels of LCS more quickly. Currently they get attached at the low level
and don't propagate up to higher levels until enough activity at a lower
level promotes the data. Meanwhile, LCS means compactions can occur in
parallel
Have you taken a look at the new stuff introduced by
https://issues.apache.org/jira/browse/CASSANDRA-7019 ? I think it may go a
ways to reducing the need for something complicated like this.
Though it is an interesting idea as special handling for bulk deletes. If they
were truly just sstables
On Tue, Feb 13, 2018 at 2:38 PM, Carl Mueller
wrote:
> In process of doing my second major data purge from a cassandra system.
>
> Almost all of my purging is done via row tombstones. While performing this
> the second time while trying to cajole compaction to occur (in 2.1.x,
> LevelledCompactio