[
https://issues.apache.org/jira/browse/CASSANDRA-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict updated CASSANDRA-6737:
--------------------------------
Attachment: 6737.2.patch
Mostly LGTM. One actual problem, and a couple of suggestions:
- Looks like in MS.addUpdatesForKey() "rows" should be being passed as the last
parameter to the constructor of "params".
- It would be nice if addUpdateForKey and addUpdatesForKey were next to each
other in MS
- Maybe fast path in unzipMutations should use values().iterator instead of
lookup based on keyspace hash. Pretty ambivalent about that though.
- Nit: unused import in BS
Attached new patch with my suggestions.
> A batch statements on a single partition should not create a new CF object
> for each update
> ------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-6737
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6737
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 2.0.6
>
> Attachments: 6737.2.patch, 6737.txt
>
>
> BatchStatement creates a new ColumnFamily object (as well as a new
> RowMutation object) for every update in the batch, even if all those update
> are actually on the same partition. This is particularly inefficient when
> bulkloading data into a single partition (which is not all that uncommon).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
