[
https://issues.apache.org/jira/browse/CASSANDRA-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13892159#comment-13892159
]
Sylvain Lebresne commented on CASSANDRA-5357:
---------------------------------------------
I've pushed an additional commit on top of the branch above at
https://github.com/pcmanus/cassandra/commits/5357-2 that adds a bunch of
comments (there is a few subtlety going on here :)), a few minor nits and:
* refactor getThroughCache() a bit so we can maximize the cases where we can
use a cached partition (typically, if a slice query bounds are fully included
in cache cf, we know we're good).
* improve a bit the handling of expiring columns: when comparing the number of
rows in a cached CF to rowsPerPartitionToCache, we should indeed not expire
columns as this could lead to think we're caching the whole partition when we
don't, but when comparing checking if the cached CF has enough rows for the
query filter, we must expire with the query TTL or we might end up return less
rows than we should (that last part wasn't done by the previous patch).
* make sure we test for !reversed in isHeadFilter()
* I've reverted to CFS.getRawCachedRow and instead have move the decision of
whether the cached row can be used to RowIteratorFactory. It didn't felt
particularly logical to do that in getRawCachedRow given nothing in the name of
the method suggests it, and it allows more easily to maximize the usage of the
cache for range queries.
* doesn't increment metric.rowCacheHit when the cached value can't be used due
to the filter, only increment metric.rowCacheHitOutOfRange, as that feels more
natural to me.
Provided that additional commit looks reasonable, I believe I'm good with this.
bq. I'll to do the row cache -> partition cache renaming in a separate ticket
Right. Though now that I think about it, row cache is not all that horrible, it
does cache rows, it just cache only some number per partition :). Maybe it's
not worth the pain of a rename. Anyway, I'm good leaving that discussion for
another time/ticket.
> Query cache / partition head cache
> ----------------------------------
>
> Key: CASSANDRA-5357
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5357
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Jonathan Ellis
> Assignee: Marcus Eriksson
> Fix For: 2.1
>
> Attachments: 0001-Cache-a-configurable-amount-of-columns.patch
>
>
> 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 was sent by Atlassian JIRA
(v6.1.5#6160)
