[
https://issues.apache.org/jira/browse/CASSANDRA-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292674#comment-13292674
]
David Alves commented on CASSANDRA-3885:
----------------------------------------
bq. but why do we need to do this?
I'm not completely sure I understood what you are asking. If you're asking why
the params specify slices in reverse order when reading reversed, it was
because I thought it would make sense to specify the ranges we want the first
results to come from, first.
If you're asking about this particular piece of code:
{code}
if (reversed && readBackwards)
currentSlice--;
else
currentSlice++;
{code}
lets say we have the following two slices [a,c] [f,j] and, in reverse [j,f]
[c,a]. In IndexedBlockFecther we always start with the first slice ([a,c] and
[j,f], respectively) and continue from there as we want to make sure we don't
fetch more than necessary. In SimpleBlockFecther however we always fetch the
whole row so we might as well process [j,f] [c,a] as if it were [a,c] [f,j] and
simply add the blocks to the queue in reverse order. that's why we read reverse
& backwards.
I hope that clarified it.
Your question reminds me of one another one I had, though. Why don't we make
the "count" information reach ISR so that we can stop at the precise point the
user query specifies? It seems wasteful to be reading the whole row in
SimpleBlockFetcher is the user only requested the first 5 cols. This wouldn't
work in reverse reads, of course, but would speed up forward ones, which are
probably the most frequent, no?
bq. In IndexedSliceReader itself is a iterator and within which there is Simple
and IndexedFetcher which is also kind of a iterator ... it might be better to
make IndexedSliceReader as abstract class and add functionality into classes.
I'm not sure I understood what you are suggesting... is it that we move the
code that decides whether we need a Simple- or IndexedBlockFetcher out of ISR
and make ISR itself the parent abstract class to Simple- or
IndexedBlockFetcher?
> 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,
> CASSANDRA-3885.patch, 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
