cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3885) Support multiple ranges in SliceQueryFilter
Date Tue, 05 Jun 2012 08:33:24 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289243#comment-13289243
] 

Sylvain Lebresne commented on CASSANDRA-3885:
---------------------------------------------

bq. simply storing anyway it in the case it is needed.

Yeah but we kind of do that in the current code already with the queue {{blockColumns}}. {{blockColumns}}
is a cache of sorts and that's why I think we shouldn't add a second one. Much like we currently
do, during deserialization we can simply check if it's worth deserializing the next column
of the block (which should only mean comparing each column once, against the "biggest" range
intersecting the index block). Then, in computeNext(), when polling the column from {{blockColumns}}
we can validate if the column is really needed (again, since we know the order in which we
poll the column, this should only require comparison to one of the range). This should be
roughly equivalent to the cache of your patch, but it avoids having both {{blockColumns}}
and the cache.
                
> 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
>
>
> 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