[
https://issues.apache.org/jira/browse/CASSANDRA-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605173#comment-13605173
]
Jonathan Ellis commented on CASSANDRA-5357:
-------------------------------------------
I'm 80% convinced that a truly generic query cache is not feasible while also
maintaining good performance. Specifically, on the write path we either need
to update cached entries or invalidate them; for sequential scans that would
mean storing scan results as an interval of rows, which is probably reasonable,
but for index scans we'd need to store cached results under the indexed row
value, and on update to an indexed column we'd need to read-before-write to
find the current value, to invalidate them.
So I'm okay with saying that we only cache results for single-partition
queries, which makes cache invalidation on update simple. It also makes it
more difficult, but not impossible, to cause yourself memory problems from
caching huge resultsets.
> Query cache
> -----------
>
> Key: CASSANDRA-5357
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5357
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jonathan Ellis
> Assignee: Vijay
>
> I think that most people expect the row cache to act like a query cache,
> because that's a reasonable model. Caching the entire partition is, in
> retrospect, not really reasonable, so it's not surprising that it catches
> people off guard, especially given the confusion we've inflicted on ourselves
> as to what a "row" constitutes.
> I propose replacing it with a true query cache.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
