[
https://issues.apache.org/jira/browse/CASSANDRA-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12726253#action_12726253
]
Jonathan Ellis commented on CASSANDRA-259:
------------------------------------------
1. I thought the comment
<!-- Key cache size is the fraction of keys per sstable whose
locations
we keep in memory in "mostly LRU" order. -->
made it clear what was going on, but we can change it to KeyCachedFraction, if
you like that better. (It's not a percent, since that is 0-100 not 0-1 :)
2. done
3: Column sizes vary a lot more than key sizes. Also it is clear that if the
client is doing a slice op on the key, we want to cache the key location, but
do we want to cache the column values? That is much less clear. Hence I think
this is best managed explicitly by the client with memcached, ehcache, etc.
> LRU cache for key positions
> ---------------------------
>
> Key: CASSANDRA-259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-259
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Attachments:
> 0001-CASSANDRA-259-encapsulate-bloom-filter-access-into-sst.txt,
> 0002-add-concurrentlinkedhashmap-cache-and-config-option.txt,
> 0003-refactor-sstable-into-SSTable-SSTableReader-and-SSTa.txt,
> 0004-per-table-cache-size.txt
>
>
> add cache like the old touch cache, but working :)
> this will mitigate the performance hit from CASSANDRA-223
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
