You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Donald Smith (JIRA)" <ji...@apache.org> on 2014/01/22 23:10:20 UTC
[jira] [Created] (CASSANDRA-6611) Allow for FINAL ttls and FINAL
(immutable) inserts to eliminate the need for tombstones
Donald Smith created CASSANDRA-6611:
---------------------------------------
Summary: Allow for FINAL ttls and FINAL (immutable) inserts to eliminate the need for tombstones
Key: CASSANDRA-6611
URL: https://issues.apache.org/jira/browse/CASSANDRA-6611
Project: Cassandra
Issue Type: New Feature
Reporter: Donald Smith
Suppose you're not allowed to update the TTL of a column (cell) -- either because CQL is extended to allow syntax like "USING *FINAL* TTL 86400" or because there were a table option saying that TTL is immutable.
If you never update the TTL of a column, then there should be no need for tombstones at all: any replicas will have the same TTL. So there’d be no risk of missed deletes. You wouldn’t even need GCable tombstones. The purpose of a tombstone is to cover the case where a different node was down and it didn’t notice the delete and it still had the column and tried to replicate it back; but that won’t happen if it too had the TTL.
So, if – and it’s a big if – a table disallowed updates to TTL, then you could really optimize deletion of TTLed columns: you could do away with tombstones entirely. If a table allows updates to TTL then it’s possible a different node will have the row without the TTL and the tombstone would be needed.
Or am I missing something?
Disallowing updates to rows would seem to enable optimizations in general. Write-once, non-updatable rows are a common use case. If cassandra had FINAL tables (or FINAL INSERTS) then it could eliminate tombstones for those too. Probably other optimizations would be enabled too.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)