[ https://issues.apache.org/jira/browse/CASSANDRA-7819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132572#comment-14132572 ]
Benedict commented on CASSANDRA-7819: ------------------------------------- I'm tempted to say we should just get rid of that executor step to absolutely guarantee it, since it really doesn't buy us anything at all - it almost certainly just slows things down. > In progress compactions should not prevent deletion of stale sstables > --------------------------------------------------------------------- > > Key: CASSANDRA-7819 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7819 > Project: Cassandra > Issue Type: Improvement > Components: Core > Reporter: Benedict > Assignee: Benedict > Priority: Minor > Labels: compaction > Fix For: 2.0.11 > > Attachments: 0001-7819-v2.patch, 7819.txt > > > Compactions retain references to potentially many sstables that existed when > they were started but that are now obsolete; many concurrent compactions can > compound this dramatically, and with very large files in size tiered > compaction it is possible to inflate disk utilisation dramatically beyond > what is necessary. > I propose, during compaction, periodically checking which sstables are > obsolete and simply replacing them with the sstable that replaced it. These > sstables are by definition only used for lookup, since we are in the process > of obsoleting the sstables we're compacting, they're only used to reference > overlapping ranges which may be covered by tombstones. > A simplest solution might even be to simply detect obsoletion and recalculate > our overlapping tree afresh. This is a pretty quick operation in the grand > scheme of things, certainly wrt compaction, so nothing lost to do this at the > rate we obsolete sstables. > See CASSANDRA-7139 for original discussion of the problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)