[
https://issues.apache.org/jira/browse/CASSANDRA-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594567#comment-13594567
]
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: https://issues.apache.org/jira/browse/CASSANDRA-5228
> 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: http://www.atlassian.com/software/jira
