cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5357) Query cache
Date Tue, 24 Sep 2013 04:06:12 GMT


Jonathan Ellis commented on CASSANDRA-5357:

bq. its not that bad to deserialize the filters at least in the stress tests i did

I think you may be testing the wrong thing.  Specifically, you have to deserialize the filters
(and the CF, as a unit!) even on a *miss*.  So the cost is quite high vs having live filters.

bq. instead of de-serializing the whole column family at once we can de-serialize it during
filter in CFS.filterColumnFamily

Okay, I get that.  I'm not concerned about that so much as, do we keep within our total memory
budget?  If we have a 2GB cache and your query/queries make us use 1GB of that on a single
CF object, that is painful but acceptable.  But if we disregard our budget and collect a 3GB
CF, that's unacceptable.

> Query cache
> -----------
>                 Key: CASSANDRA-5357
>                 URL:
>             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:

View raw message