[jira] [Commented] (CASSANDRA-5357) Query cache / partition head cache

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

    [ 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)