[
https://issues.apache.org/jira/browse/CASSANDRA-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-172:
-------------------------------------
Attachment: 172-addendum-v2.patch
You are right, my way is not much of an improvement in that what it gains from
a simpler loop it loses in duplicating too much of the addColumn internals.
So here is a third approach. I add a ReducingIterator that is in charge of
merging runs of "equal" objects into a single one. (This is also useful in
getKeyRange, and probably other places). Then we have our reduction be an
addColumn, and post-reduce all we have to do is iterate the results and check
if the merged column is deleted.
I also use AbstractIterator from google collections
(http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/AbstractIterator.html)
to make defining "real" iterators from the SF easier (and similarly in
FileStruct). You can grab a copy here:
http://google-collections.googlecode.com/files/google-collect-1.0-rc1.zip
This works out to be slightly more verbose (in part to our damned
brace-on-new-line policy) but I think it's more maintainable overall since each
step in the process is now easily understood at a glance.
> 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: 172-addendum-SF.patch, 172-addendum-v2.patch,
> 172-addendum.patch, get_slice_from.patchv1, get_slice_from.patchv2,
> get_slice_from.patchv3
>
>
> 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.