Attaching patches for that (also pushed to https://github.com/pcmanus/cassandra/commits/5125).
The first part of this ticket is about how we store the information that a clustering key column is indexed. Turns out that for "regular" columns we use ColumnDefinition and the indexing code also assumes that, so the probably best and simplest approach is to reuse ColumnDefinition for that too. But then it's easier to always store all primary key columns as ColumnDefinition, pretty much obsoleting the old key_aliases and column_aliases. There is a few related details worth noticing:
- while this obsolete the aliases, those are not removed of the schema by the patch for compatibility sake. Truth is, I'm not sure there is a way to remove a field from the schema without breaking rolling upgrades at this point.
- after this patch, CFDefinition becomes much less useful as CFMetadata + ColumnDefinition holds pretty much the same information in pretty much the same form. So we could slightly simplify things by removing CFDefinition. However, this is left to later (this won't be a 3 lines patch).
After that, the patch adds a new type of composite indexes to handle indexing clustering keys (which share most code with the existing regular composite index) and update CQL3 to allow adding and querying the new indexes (in particular, it is slighty tricky in SelectStatment to recognize when a clustering key is restricted if 2ndary indexes should be used or not).
The last patch adds support for indexing components of the partition key (we don't allow indexing the first component of the partition key as it makes no sense (it's already primary indexed), but if the partition key is composite, secondary indexing the 2+ parts can be useful).
Lastly, I'll note that the patches only add theses news indexes for non compact tables. We should generalize to compact tables too, but that would require a bit of generalization that I'd rather add in a second phase.