Thanks, Benedict. Is this only true as of 3.x (new storage engine), or was the equivalent efficiency also true with 2.x?
It would be good to have an explicit statement on this efficiency question in the spec/doc since the spec currently does say: "The option also *provides a slightly more compact layout of data on disk* but at the price of diminished flexibility and extensibility for the table." So, if that "slightly more compact layout of data on disk" benefit is no longer true, away with it. See: https://cassandra.apache.org/doc/cql3/CQL-3.0.html And I would recommend that your own statement be added there instead. -- Jack Krupansky On Mon, Apr 11, 2016 at 5:03 PM, Jeremiah Jordan <jerem...@datastax.com> wrote: > As I understand it "COMPACT STORAGE" only has meaning in the CQL parser > for backwards compatibility as of 3.0. The on disk storage is not affected > by its usage. > > > On Apr 11, 2016, at 3:33 PM, Benedict Elliott Smith <bened...@apache.org> > wrote: > > > > Compact storage should really have been named "not wasteful storage" - > now > > everything is "not wasteful storage" so it's void of meaning. This is > true > > without constraint. You do not need to limit yourself to a single non-PK > > column; you can have many and it will remain as or more efficient than > > "compact storage" > > > > On Mon, 11 Apr 2016 at 15:04, Jack Krupansky <jack.krupan...@gmail.com> > > wrote: > > > >> My understanding is Thrift is being removed from Cassandra in 4.0, but > will > >> COMPACT STORAGE be removed as well? Clearly the two are related, but > >> COMPACT STORAGE had a performance advantage in addition to Thrift > >> compatibility, so its status is ambiguous. > >> > >> I recall vague chatter, but no explicit deprecation notice or 4.0 plan > for > >> removal of COMPACT STORAGE. Actually, I don't even see a deprecation > notice > >> for Thrift itself in CHANGES.txt. > >> > >> Will a table with only a single non-PK column automatically be > implemented > >> at a comparable level of efficiency compared to the old/current Compact > >> STORAGE? That will still leave the question of how to migrate a > non-Thrift > >> COMPACT STORAGE table (i.e., used for performance by a CQL-oriented > >> developer rather than Thrift compatibility per se) to pure CQL. > >> > >> -- Jack Krupansky > >> >
