cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Assigned] (CASSANDRA-5546) Gc_grace should start at the creation of the column, not when it expires
Date Tue, 01 Mar 2016 16:04:18 GMT


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:
>             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

This message was sent by Atlassian JIRA

View raw message