cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Alves (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3885) Support multiple ranges in SliceQueryFilter
Date Fri, 01 Jun 2012 18:46:23 GMT


David Alves commented on CASSANDRA-3885:

Hi Vijay

 Sorry for the delay also, somehow I didn't get notified that the issue was updated/commented.
 1) - With regard to SliceRange you're right, I just wanted to get some feedback before changing
thrift stuff
 2) - We can definitely avoid that, maybe make IndexedSliceReader receive the ranges as an
 3) - Hadn't thought about that... maybe we could have a internal (within org.apache.cassandra.db)
version and transform?
 4) - Cacheing the results is not about query validation, at least I can't see how better
query validation would discard the necessity of cacheing to avoid re-reads. There is always
a scenario where cacheing the results avoids re-reads (when we're sure that the next reversed
range will need them), the thing is that right now we're cacheing without knowing that they
wether they will be necessary (vs making sure the previous range will need them). In any case
the maximum that gets cached is an index range of records per query so that might not be a
terrible issue. What do you think?
> Support multiple ranges in SliceQueryFilter
> -------------------------------------------
>                 Key: CASSANDRA-3885
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Vijay
>             Fix For: 1.2
>         Attachments: 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:!default.jspa
For more information on JIRA, see:


View raw message