[
https://issues.apache.org/jira/browse/CASSANDRA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798747#action_12798747
]
Jonathan Ellis commented on CASSANDRA-678:
------------------------------------------
It wouldn't be hard to add an absolute number of rows as an option (GB would be
much more expensive to measure), but I'm trying to do the smallest amount that
is actually useful in this ticket. (as usual :)
> row-level cache
> ---------------
>
> Key: CASSANDRA-678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-678
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.9
>
> Attachments: 0001-basic-caching.txt,
> 0002-clean-up-onstart-to-fix-cache-size-calculation.txt,
> 0003-instrumentation.txt,
> 0004-make-rowcache-keycache-configurable-per-CF.txt,
> 0005-combine-SSTable-keycaches-into-one-at-CFS-level.-do-no.txt,
> 0005-update-cached-rows-in-place-instead-of-invalidating-.patch
>
>
> We have a key cache but that doesn't help mitigate the expensive
> deserialization of the actual data to return.
> Adding a row-level cache should be fairly simple using a
> ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only
> cache whole rows at a time, since already know how to query on those
> in-memory. This limits us to CFs full of narrow rows but that is a common
> enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
