[ 
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

        

Reply via email to