[
https://issues.apache.org/jira/browse/CASSANDRA-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Oskarsson updated CASSANDRA-821:
--------------------------------------
Attachment: CASSANDRA-821.patch
Updated version of the patch incorporating some of ideas from Jonathan's
comment.
* The scanner now returns the correct column iterator based on the filter
provided (or lack thereof).
* The reducing iterator in ColumnFamilyStore returns the row straight away
without the need for a final step
There are two cosmetic details though that I'd like a comment on from someone
* I had to expose a method in the ColumnIterators to seek to the start of the
row since the collating iterator will go one row too far to compare row keys.
Any advice on how we can make this nicer is welcome.
* I don't think I did the reducing iterator implementation the way you had in
mind. I don't quite get how the ColumnIterator in the reduce method can be made
into a ColumnFamily without the other iterators for the same row present? So
that I can use ColumnFamily.addAll
> get_range_slice performance
> ---------------------------
>
> Key: CASSANDRA-821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-821
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 0.6
> Reporter: Brandon Williams
> Assignee: Johan Oskarsson
> Priority: Minor
> Fix For: 0.7
>
> Attachments: CASSANDRA-821.patch, CASSANDRA-821.patch
>
>
> get_range_slice performance isn't that great. CASSANDRA-799 helped in the
> case when the memtable isn't flushed, but overall the operations per second
> and latency is still pretty bad. On a quad core node with a trivial amount
> of data I see around 130-150 ops per second with stress.py set to slice 100
> keys at a time, and latency is 300-500ms.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
