[
https://issues.apache.org/jira/browse/CASSANDRA-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864526#action_12864526
]
Stu Hood edited comment on CASSANDRA-1046 at 5/13/10 7:54 PM:
--------------------------------------------------------------
That's only one of the bullet points on #998: please wait to see the code
before vetoing it entirely.
EDIT: Having posted the first patch for #998, I agree that it no parts of it
should touch 0.7. But, we should still consider the fact that 998 will be
coming with 0.8, and weigh the benefits of fixing this issue against fixing
other issues that don't touch queries/column iteration.
was (Author: stuhood):
That's only one of the bullet points on #998: please wait to see the code
before vetoing it entirely.
> optimize Memtable.getSliceIterator
> ----------------------------------
>
> Key: CASSANDRA-1046
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1046
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Fix For: 0.7
>
>
> As reported by James Golick, about 30% of the time in a read is spent in
> SliceQueryFilter.getMemColumnIterator, virtually all of which is in
> ConcurrentSkipListMap$Values.toArrray().
> I wrote on the ML:
> Besides the UUID optimization you posted, we should do an audit of
> ColumnFamily.getSortedColumns and replace with iteration where possible (in
> this case, we'd be left with one copy of most of the columns, but that's
> better than two).
> We can get rid of the other copy by fixing the logic in
> Memtable.getSliceIterator, which says "copy all the columns, so we can do a
> binary search on them to find where to start," but since columns are natively
> in sorted order we could just use an iterator and a while loo
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
