Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 28 Oct 2014 16:14:34 +0000 (UTC)
From: "sankalp kohli (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12717664.1401487231000.354912.1414512874358@Atlassian.JIRA>
In-Reply-To: <JIRA.12717664.1401487231000@Atlassian.JIRA>
References: <JIRA.12717664.1401487231000@Atlassian.JIRA>
 <JIRA.12717664.1401487231549@arcas>
Subject: [jira] [Commented] (CASSANDRA-7331) Improve Droppable Tombstone
 compaction
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-7331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14187009#comment-14187009 ] 

sankalp kohli commented on CASSANDRA-7331:
------------------------------------------

If I understand correctly, your goal here is, given a bunch of candidates to perform tombstone-compaction on, let's order them by which is likely to clean up the most. Right?

Yes. I agree on this. Let me close this.

> Improve Droppable Tombstone compaction
> --------------------------------------
>
>                 Key: CASSANDRA-7331
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7331
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: sankalp kohli
>            Priority: Minor
>              Labels: compaction
>
> I was thinking about this idea so creating a JIRA to discuss it. 
> Currently we do compaction for stables which have more than configurable number of droppable tombstones. 
> Also there is another JIRA CASSANDRA-7019 to do compactions involving multiple stables from different levels which will be triggered based of same threshold. 
> One of the areas of improvement here to pick better candidates will be to find out if a tombstone can actually get rid of data in other stables. 
> We can add a byte to tombstone to keep track of whether it has knocked off the actual data(for which it is there) or not. 
> All tombstones will start out with 0 as its value. When it compacts with other stables and causes data to be deleted, it will be incremented. 
> For cases where there are multiple updates and then a delete, this value can be more than 1 depending on how many updates came in before delete. 
> If we have this, by looking at these numbers in tombstones, we can find a stable which by compacting, we will get rid of maximum data. We can also add a global number per stable which sums up these numbers. 
> I am not sure how this will work with range tombstones and whether this will be useful.   


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)