cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5228) Track maximum ttl and use to expire entire sstables
Date Wed, 06 Mar 2013 10:12:13 GMT


Sylvain Lebresne commented on CASSANDRA-5228:

bq. another approach might be to say that DeletedColumn TTL is gc_grace_seconds?

Kind of, but I wouldn't put it that way exactly. I don't think we should track ttl per-se,
but rather the maximum time at which all columns in the sstable are deleted. I.e. we should
track the max localDeletionTime (which is MAX_VALUE for normal columns, which is what we want).
So there shouldn't be any special casing of tombstone versus expired column in that ticket
in that the Colum.getLocalDeletionTime() does the right thing already.

And thus dropping sstable should just be checking if current_time > max(localDeletionTime).
Though for the record, I note that having all column GCable is *not* sufficient to drop the
sstable, we'd typically need to check that the sstable maxTimestamp is smaller than all other
sstable minTimestamp. Otherwise, we might drop tombstone (or expiring columns for that matter)
that are GCable but shard another column in another sstable.
> Track maximum ttl and use to expire entire sstables
> ---------------------------------------------------
>                 Key: CASSANDRA-5228
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jonathan Ellis
>            Assignee: Marcus Eriksson
>            Priority: Minor
>         Attachments: 0001-track-max-ttl-v1.patch
> It would be nice to be able to throw away entire sstables worth of data when we know
that it's all expired.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message