[
https://issues.apache.org/jira/browse/CASSANDRA-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1839:
--------------------------------------
Component/s: Core
Priority: Minor (was: Major)
Fix Version/s: (was: 0.7.1)
note that this requires doing a full-row read on writes of row-level
tombstones, otherwise there is a potential bug of assuming columns are
supressed when they actually have a higher timestamp than the tombstone you are
writing.
i'm skeptical that this is worth doing for a single use case.
> 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.
