Seems like a reasonable idea to me. I recall that we didn't implement this last time for two reasons: 1) the 4.0 freeze was in effect so we avoided introducing more public surface area (the table option) and 2) we couldn't present a reason at the time why someone would need to set this at a table level. The main case we could think of was if someone was running a backup procedure that (incorrectly) assumed all sstables in Cassandra are compressed identically; this is why we left the "table" option to flip the whole node.
Just curious, what is the use case you're seeing where users need to configure this? Is it that they have one Zstd/Deflate table that needs to flush with the same compressor, but they don't want all the others flushing slowly? Maybe a table which defers compaction long enough that the extra disk space before the first deferred compaction becomes significant? I'm just thinking about when we would recommend users deviate from "auto"? Thank you for tackling this! -Joey On Mon, Sep 7, 2026 at 6:52 AM Bernardo Botella <[email protected]> wrote: > > I’m +1 for the functionality. > > From: Štefan Miklošovič <[email protected]> > Date: Monday, 7 September 2026 at 12:07 > To: dev <[email protected]> > Subject: [DISCUSS] flush_compression as a parameter in CQL schema > > I want to formally run this (1) through dev ML and gather the approval > for the introduction of this functionality as it technically changes > CQL. > > Thanks and regards > > (1) https://issues.apache.org/jira/browse/CASSANDRA-21642
