[ https://issues.apache.org/jira/browse/CASSANDRA-6630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13886734#comment-13886734 ]
Sylvain Lebresne commented on CASSANDRA-6630: --------------------------------------------- bq. This could be severely pathological behaviour for large modification statements. It might not be optimal for really large modifications, true. "severely pathological" sounds a bit like over-dramatization for effect though imo (especially since really large modifications is not what we particularly optimize for so should be rather uncommon). Anyway. bq. why not add everything in unsorted order and then sort/merge prior to a call to any of the accessors? Why not, though I'll note this could easily back-fire performance wise if some accesses are intermingled with adds. I don't think we do that with ABSC, at least not in place where it would be a big performance problem, but it feels like something that can be easily introduced by accident later. Not a huge deal I guess, but if we're gonna end up with an implementation for which performance is a little bit harder to reason about, it could be worth asserting what actual benefits it gets us? Maybe in a followup ticket. > Replace UnsortedColumns with ArrayBackedSortedColumns > ----------------------------------------------------- > > Key: CASSANDRA-6630 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6630 > Project: Cassandra > Issue Type: Improvement > Reporter: Aleksey Yeschenko > Assignee: Aleksey Yeschenko > Fix For: 2.1 > > Attachments: 6630.txt > > > It's possible for a counter mutation to have several CounterUpdateCell-s with > the same cell name. Those should be summed up and not ignored. -- This message was sent by Atlassian JIRA (v6.1.5#6160)