[
https://issues.apache.org/jira/browse/CASSANDRA-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287594#comment-13287594
]
David Alves edited comment on CASSANDRA-3885 at 6/1/12 11:48 PM:
-----------------------------------------------------------------
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 array?
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 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?
was (Author: dr-alves):
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 array?
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: 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
>
>
> 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
