[
https://issues.apache.org/jira/browse/CASSANDRA-821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845480#action_12845480
]
Jonathan Ellis commented on CASSANDRA-821:
------------------------------------------
This is a huge step in the right direction.
The main cleanup that needs to happen is, the sstable iterator should take the
same QueryFilter `filter` as the memtable ones, so that the reducing iterator
can indeed reduce to a single Row (via cf.addall) and the "pull rows out of the
iterator" step stays simple, w/o a second round of filtering.
readColumnsForRow should go away entirely this way.
(Table.flusherLock only needs to be acquired for accesses to CFS.memtable
variable, btw. I've updated the comment in its definition to make this more
clear.)
Minor point: by convention, IteratingRow should become IIteratingRow, and needs
apache license header.
> 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
>
>
> 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.
