Based on recent discussions determining whether or not this can go into 3.2.1 (or any 3.2.x release) may come down whether or not the change can be done through our patch process. Currently the patch process does not allow for database schema changes. This is because schema changes are done through the installer and the installer might not be run as part of the patch process. This means that any Cassandra schema changes would need to be applied at server start up which is easy enough to do. Where things might get a bit complicated is with an HA deployments where multiple servers start up at the same time and apply schema updates concurrently. I do not think this will be a problem because Cassandra has support for concurrent schema modifications. For reference see the following, * https://issues.apache.org/jira/browse/CASSANDRA-1391 * http://www.datastax.com/dev/blog/the-schema-management-renaissance * https://issues.apache.org/jira/browse/CASSANDRA-3794
I want to clarify a couple things in comment 1. First, this applies only to Cassandra schema changes and not to the relational database schema. Secondly, with small changes this could meet the criteria for patches. This would be a big improvement for customers. The footprint on disk could be reduced by as much as 60%. This could also have a big impact on performance of not just the Storage Node but also the platform on which it is running. People expressed concern about the footprint on disk prior to 3.2.0 going out. In fact, it is those concerns that led to the in-depth sizing analysis performed by Stefan Negrea and me. I am requesting that this be triaged for 3.2.1 (or even 3.2.2).
Moving to ON_QA since these changes were in ER1. Based on what I have seen in 3.2.x environments, I think that compression needs to be configurable so users have a way to easily turn it off if. I will open a separate BZ for that.