[jira] Issue Comment Edited: (CASSANDRA-1839) Keep a tombstone cache

["Brandon Williams (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971023#action_12971023 ] 

Brandon Williams edited comment on CASSANDRA-1839 at 12/13/10 3:28 PM:
-----------------------------------------------------------------------

I see, but that is only if we are proactively populating the cache.  I was thinking we would do it after the first merge-on-read that resulted in a row-level tombstone.  Essentially what row cache is doing now, but cheaper.

      was (Author: brandon.williams):
    I see, but that is only if we are proactively populating the cache.  I was thinking we would do it after the first merge-on-read that resulted in a row-level tombstone.
  
> 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.