Hi Jindal,
Thanks for the questions. As Stefan mentioned (thanks to Stefan too), ZSTD
dictionary compression is toggled via DDL at the table level. It is exactly
the same way we configure compression for tables as of today. It is
captured in the "New or Changed Public Interfaces" section of the CE
On a related note, I don't recall if we have any way to allowlist
compression strategies as admins? If not, it would be very helpful where
the DB operator wants to avoid users that forget or do not set compression
in their schema. If the compression is left off, we should default to
something sensi
Hi,
in table schema, there would be table compression configuration. Like new
options for enabling compression, sampling strategy etc.
Then in cassandra.yaml, auto train, auto prune obsolete dics, training
frequency, acceptance percentage, dictionary size and memory limits etc.
I took this from
Hi Bernardo,
Thanks for bumping up the discussion.
I plan to schedule the vote for next week.
If anyone has any comments or concerns, please let me know so that I
can incorporate them into the CEP. The general design remains the
same, and with picolci taking his place we can reuse the same comman
Noted with thanks.
I agree that it does not need to be zstd specific. The additional dict
information for CompressionInfo are dictionary id, dictionary bytes and
checksum of id and content. It should be common for other dictionary-based
compression algorithms. In terms of implementation, I will ke
