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

Jonathan Ellis commented on CASSANDRA-172:
------------------------------------------

> For the CF wrapper, I need to resolve a column at a time so that I know when 
> I have enough columns to return (since a column could be deleted). 

It's O(N^2) to do a "for 1..N: L.add(cf2); resolve(L)" so that really needs to 
be avoided.  (even just removeDeleted is O(N) so don't nest that either.)  SC 
removeDeleted in particular does a ton of allocations, it's not intended to be 
called repeatedly.

Since we are only concerned about counting top-level IColumns (even if this is 
called on a super CF) then manually resolving is easy: "if column is live: 
cf.addColumn(column)"

> I am not exactly sure how to apply your addColumn suggestion, since there is 
> no place to call a single final resolve. 

I don't understand the dillemma.  building up a CF as described and then 
"return removeDeleted(cf)" takes care of it.  There is no resolving to do this 
way.

> If all iterators are empty, an empty CF will be returned. I don't really need 
> to update the tombstone in the CF unless for read-repair considerations. 
> However, the current read-repair logic doesn't deal with CF removal. 

Better to preserve correct behavior re CF tombstones when returning a CF than 
be surprised by it later, especially when there is no pain in doing so.  No?


> A improved and more general version of get_slice
> ------------------------------------------------
>
>                 Key: CASSANDRA-172
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-172
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Jun Rao
>            Assignee: Jun Rao
>             Fix For: 0.4
>
>         Attachments: get_slice_from.patchv1, get_slice_from.patchv2
>
>
> Today, get_slice has to scan through all columns in every memtable and 
> sstable to get a slice of columns. This becomes inefficient when the number 
> of columns in a row is large. We need a more efficient API.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to