[
https://issues.apache.org/jira/browse/CASSANDRA-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13629695#comment-13629695
]
Vijay commented on CASSANDRA-5357:
----------------------------------
{quote}
I don't follow – how can you have both O(1) [Map key is the row key] and also
promote QF into the key?
{quote}
Well I am talking about the best case, where the queries are fairly limited on
the rows.
{quote}
We're talking about K=Map Key, right? How do you see QF increasing by row size?
{quote}
K (Map Key) where K is a list of queries, (RowKey + [<start,end>,<columns[]>]).
NOTE: we will only hash/equals based of the rowKey and not the entier Map Key,
once we reach the map key we can verify if the particular query exist in the
key by a linear scan.
The value being a set of columns which match all the Key's queries....
The main reason for complicating the above is to avoid 2 maps (POC code in
#1956 does that), one to map <RowKey, Query> and other to hold the actual query
<Query, CF> to help invalidate or even update the cache when there is an update.
> 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
