[ https://issues.apache.org/jira/browse/CASSANDRA-5546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne reassigned CASSANDRA-5546: ------------------------------------------- Assignee: Sylvain Lebresne > Gc_grace should start at the creation of the column, not when it expires > ------------------------------------------------------------------------ > > Key: CASSANDRA-5546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5546 > Project: Cassandra > Issue Type: Improvement > Reporter: Sylvain Lebresne > Assignee: Sylvain Lebresne > Fix For: 3.x > > > Currently, gc_grace determines "the minimum time we keep a column that has > been marked for deletion", where "marked for deletion" is creation time for a > DeletedColumn or the expiration time for an ExpiringColumn. > However, in the case of expiring columns, if you want to optimize deletions > while making sure you don't resurrect overwritten data, you only care about > keeping expired columns gc_grace seconds *since their creation time*, not > *since their expiration time*. It would thus be better to have gc_grace be > "the minimum time we keep a column since it's creation" (which would change > nothing for tombstones, but for TTL would basically ensure we remove the > expiration time from the time we keep the column once expired). > To sum it up, this would have the following advantages: > # This will make fine tuning of gc_grace a little less of a black art. > # This will be more efficient for CF mixing deletes and expiring columns > (we'll remove tombstones for the expiring one sooner). > # This means gc_grace will be more reliable for things like CASSANDRA-5314. > Doing this is pretty simple. The one concern is backward compatilibity: it > means people that have fine tuned gc_grace to a very low value because they > knew it was ok due to their systematic use of ttls might have to update it > back to a bigger, more reasonable value before updates. -- This message was sent by Atlassian JIRA (v6.3.4#6332)