As Jeremiah indicates, it's 3.0+ only. The docs should definitely reflect this
On Mon, 11 Apr 2016 at 16:21, Jack Krupansky <jack.krupan...@gmail.com> wrote: > 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 > > >> > > >
