[
https://issues.apache.org/jira/browse/CASSANDRA-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13774291#comment-13774291
]
Vijay edited comment on CASSANDRA-5357 at 9/23/13 4:48 AM:
-----------------------------------------------------------
Hi Jonathan, I have pushed a version with sentinel (might have made it little
hackie, but it works)
https://github.com/Vijay2win/cassandra/commits/query_cache_v2.
{quote}
Serializing the entire QueryCacheValue for each lookup is going to kill
performance on hot partitions.
{quote}
It is required because we need to know the query which populated the cache, for
example there can be a named query for Column A, Z which can be followed by a
slice query from A to Z and we might not respond with the right response since
B to Y is not in the cache.
In a separate ticket we can also optimize the above case (and more) cache
query's stored, if thats ok. Example: If the slice with count as 250 is stored
we might not need to store the slice with count of 50 with same range, we can
also merge overlapping slices etc.
{quote}
if there's room, that's fine, but exceeding the configured memory budget is Bad
{quote}
Can we do that in a separate ticket?, i believe we can achieve this by
implementing a Iterator which will be similar to SSTableIterator to stream the
columns than constructing the ColumnFamily at once.
Thanks!
was (Author: vijay2...@yahoo.com):
Hi Jonathan, I have pushed a version with sentinel (might have made it
little hackie, but it works)
https://github.com/Vijay2win/cassandra/commits/query_cache_v2.
{quote}
Serializing the entire QueryCacheValue for each lookup is going to kill
performance on hot partitions.
{quote}
It is required because we need to know the query which populated the cache, for
example there can be a named query for Column A, Z which can be followed by a
slice query from A to Z and we might not respond with the right response since
B to Y is not in the cache.
In a separate ticket we can also optimize the above case (and more) cache
query's stored, if thats ok. Example: If the slice with 250 is stored why to
also store the slice with 50 in the same range, we can also merge overlapping
slices etc.
{quote}
if there's room, that's fine, but exceeding the configured memory budget is Bad
{quote}
Can we do that in a separate ticket?, i believe we can achieve this by
implementing a Iterator which will be similar to SSTableIterator to stream the
columns than constructing the ColumnFamily at once.
Thanks!
> 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
