[
https://issues.apache.org/jira/browse/CASSANDRA-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288972#comment-13288972
]
David Alves commented on CASSANDRA-3885:
----------------------------------------
Thanks for reviewing and for your input Vijay.
Now I understand what you were saying, but cacheing is used in a different
circumstance. In fact the IndexedReader assumes that the query has already been
adequately rewritten and that ranges are in order (either forward or reverse)
and non-overlapping.
Cacheing is used in the following, very particular, circumstance, lets say we
the following columns: a, b, c, d, e, f and that index segments cover the
columns as such i1=[a-c] i2=[e-f] and that we want the following (reversed)
ranges [f-e] [d-b]. We start by looking for the index segment for "f" which
falls into i2 and we'll deserialize columns d through f. Now while the the
current range we're looking for only needs "e" and "f" we have also
deserialized "d". Had we not cached "d" we would have to re-read the "d" to
handle the next range (now [d-b]), but because we cached it we don't. In
general if the next range requires any of the data we've already read we're
sure to have it in cache and won't need to re-read, if it doesn't we clear the
cache.
As you can see it's a very particular optimization for indexed, reverse reads.
> Support multiple ranges in SliceQueryFilter
> -------------------------------------------
>
> Key: CASSANDRA-3885
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3885
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: David Alves
> Fix For: 1.2
>
> Attachments: CASSANDRA-3885.patch, CASSANDRA-3885.patch
>
>
> This is logically a subtask of CASSANDRA-2710, but Jira doesn't allow
> sub-sub-tasks.
> We need to support multiple ranges in a SliceQueryFilter, and we want
> querying them to be efficient, i.e., one pass through the row to get all of
> the ranges, rather than one pass per range.
> Supercolumns are irrelevant since the goal is to replace them anyway. Ignore
> supercolumn-related code or rip it out, whichever is easier.
> This is ONLY dealing with the storage engine part, not the StorageProxy and
> Command intra-node messages or the Thrift or CQL client APIs. Thus, a unit
> test should be added to ColumnFamilyStoreTest to demonstrate that it works.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
