cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stu Hood (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-1891) large supercolumn deserialization invokes CSLM worst case scenario
Date Tue, 04 Jan 2011 22:51:46 GMT


Stu Hood commented on CASSANDRA-1891:

> That's why this patch uses the CSLM constructor which takes a SortedMap
Apologies: don't know how I missed that part.

My suggestion regarding the TreeMap was to make ColumnSortedMap extend TreeMap, and override
the methods that we need overridden (it looks like the only methods are comparator() and entrySet()).
This would eliminate all of the empty UnsupportedOperationException methods.

With or without that change, this looks fine to me. +1

> large supercolumn deserialization invokes CSLM worst case scenario
> ------------------------------------------------------------------
>                 Key: CASSANDRA-1891
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Cliff Moon
>            Priority: Minor
>             Fix For: 0.7.1
>         Attachments: 1891-v2.txt, supercolumn.patch
> SuperColumn deserialization hits a worst case insert scenario for CSLM: inserting pre-sorted
entries one at a time.  Inside of CSLM this requires scanning to the end of the list and doing
a comparison at every step for every item inserted.  This patch supplies a SortedMap interface
to the supercolumn deserialization.  CSLM will do a bulk insert from a SortedMap interface
supplied in the constructor.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message