[
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)
