[
https://issues.apache.org/jira/browse/CASSANDRA-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971021#action_12971021
]
Jonathan Ellis commented on CASSANDRA-1839:
-------------------------------------------
bq. Why do we have to do a full-row read
Say I have row K with column X and Y at timestamps 0 and 10.
I get a delete on row K @ ts 9.
If I mark K tombstoned in the key cache I will be incorrectly supressing column
Y. Hence, the need to do a full-row read to check when you do the tombstone
write. (I think you'd even need an exclusive lock while doing the check, too.)
> Keep a tombstone cache
> ----------------------
>
> Key: CASSANDRA-1839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1839
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Affects Versions: 0.3
> Reporter: Brandon Williams
> Priority: Minor
>
> There is a use case in production where the pattern is read-then-delete,
> where most of the keys read will not exist, but be attempted many times. If
> the key has never existed, the bloom filter makes this operation cheap,
> however if the key has existed, especially if it has been overwritten many
> times and thus spans multiple SSTables, the merge-on-read just to end up with
> a tombstone can be expensive. This can be mitigated with keycache and some
> rowcache currently, but this can be further optimized by storing a sentinel
> value in the keycache indicating that it's a tombstone, which we can
> invalidate on new writes to the row.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
