[ https://issues.apache.org/jira/browse/CASSANDRA-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14624429#comment-14624429 ]
Benedict edited comment on CASSANDRA-9708 at 7/13/15 9:35 AM: -------------------------------------------------------------- Yeah, that's pretty much my position. I'll note it doesn't make it a _whole_ lot simpler, so I don't think it's super important, since it's also pretty isolated. I'm personally on the fence, if not slightly leaning in favour of retaining the lack of limit. But we do have a tendency to try to stop users making terrible decisions, and they don't come more terrible than 33+ clustering columns. (Also from a testing POV, we can test serialization in isolation with 33+, but kind of difficult to do full extensive testing with that, so we may miss some coverage) was (Author: benedict): Yeah, that's pretty much my position. I'll note it doesn't make it a _whole_ lot simpler, so I don't think it's super important, since it's also pretty isolated. I'm personally on the fence, if not slightly leaning in favour of retaining the lack of limit. But we do have a tendency to try to stop users making terrible decisions, and they don't come more terrible than 33+ clustering columns. > Serialize ClusteringPrefixes in batches > --------------------------------------- > > Key: CASSANDRA-9708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9708 > Project: Cassandra > Issue Type: Sub-task > Components: Core > Reporter: Benedict > Assignee: Benedict > Fix For: 3.0.0 rc1 > > > Typically we will have very few clustering prefixes to serialize, however in > theory they are not constrained (or are they, just to a very large number?). > Currently we encode a fat header for all values up front (two bits per > value), however those bits will typically be zero, and typically we will have > only a handful (perhaps 1 or 2) of values. > This patch modifies the encoding to batch the prefixes in groups of up to 32, > along with a header that is vint encoded. Typically this will result in a > single byte per batch, but will consume up to 9 bytes if some of the values > have their flags set. If we have more than 32 columns, we just read another > header. This means we incur no garbage, and compress the data on disk in many > cases where we have more than 4 clustering components. > I do wonder if we shouldn't impose a limit on clustering columns, though: If > you have more than a handful merge performance is going to disintegrate. 32 > is probably well in excess of what we should be seeing in the wild anyway. -- This message was sent by Atlassian JIRA (v6.3.4#6332)