> > - CASSANDRA-5220: Repair improvements when using vnodes
That definitely deserves a "performance" tag. Yuki, are you looking at this or should we unassign in case somebody else wants to jump in? On 15 April 2014 14:59, Michael Shuler <mich...@pbandjelly.org> wrote: > On 04/15/2014 08:28 AM, Benedict Elliott Smith wrote: > >> It's only been six months since the last performance drive, and 2.1 is now >> around the corner. But I'm hoping we can push performance even further for >> 3.0. With that in mind, I've picked out what I think are the nearest term >> wins to focus on. >> >> - CASSANDRA-7039: DirectByteBuffer compatible LZ4 methods >> - CASSANDRA-6726: RAR/CRAR off-heap >> - CASSANDRA-6633: Dynamic bloom filter resizing >> - CASSANDRA-6755: Optimise CellName/Composite comparisons for >> NativeCell >> - CASSANDRA-7032: Improve vnode allocation >> - CASSANDRA-6809: Compressed Commit Log >> - CASSANDRA-5663: write batching in native protocol >> - CASSANDRA-5863: In-process (uncompressed) page cache >> - CASSANDRA-7040: Replace read/write stage with per-disk access >> coordination >> - CASSANDRA-6917: enum data type >> - CASSANDRA-6935: Make clustering part of primary key a first order >> >> component in the storage engine >> >> I've arranged them in ascending order of my intuitive impression of their >> difficulty. Don't all leap at the last few :) >> >> Anything I've missed? >> > > - CASSANDRA-5220: Repair improvements when using vnodes > > Not sure where that might go in your difficulty ordering, but since vnodes > are default and repair time seems to be a pretty common question/pain, it's > important for ops and highly relevant to cluster performance. If some of > the above list might directly affect/help repair performance, let's get > them tied together in Jira :) > > -- > Kind regards, > Michael > >
