cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Alves (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3885) Support multiple ranges in SliceQueryFilter
Date Mon, 11 Jun 2012 07:43:46 GMT

    [ 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

        

Mime
View raw message