Yes, you already said it. Also some write patterns, like TWCS* with long compaction windows, the compaction might never get a chance to perform early enough so data will stay on disk compressed with something they would not be compressed with if it did. Also we can't satisfy both holding a high-ingest table that must not stall flushes and a cold table that wants its compression ratio immediately.
We have also introduced CEP-49 where we enabled the integration of hardware-backed acceleration, which might compress faster to such an extent that setting flush compression to it would be something they could not have entertained before for some of their tables. I don't understand why it is in yaml only, we have to restart a node. If you know in advance what you want your cluster to use for, good for you, but if somebody wants to do this in runtime why would we force them to restart the whole cluster if it is not necessary? *For that TWCS specifically, what I see is that there might be a TWCS table with windows there is only one SSTable in, and if that table is e.g. said to be compressed with Zstd while we use flush_compression: fast in yaml and it is flushed with LZ4, then it might happen that normally (no major compaction and similar, just background compaction) that SSTable will not be re-compressed with Zstd. We might have a bunch of SSTables on disk compressed with LZ4 while their table compression is Zstd just because no compaction covered them (or ruled them out). I have a JUnit / bash script simulating this. Maybe this is something to fix in TWCS (like re-check that a window with one SSTable is on the correct compressor before skipping it) but it is an instance where we say to a user that we will compress their tables with one compressor but it is compressed with another. On Mon, Sep 7, 2026 at 3:23 PM Joseph Lynch <[email protected]> wrote: > > 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
