The block codec compresses the whole encoded region per chunk and discards it when it declines: +25% write CPU on incompressible data

[OffgridwithJD]

PgColumnarFsstHelpsCompressed runs two full block compressions per verdict and pfrees both, using them only for their lengths. On data the codec cannot compress, every byte of that work is discarded, and it is measurable: lz4 costs +24.8% write CPU on the incompressible shape.

From #890's phase 1 (@jdatcmd's measurement), filed separately because #890 closes as "change nothing about the default" and this is a cost that stands whatever the default is.

Verified in source

src/columnar_encoding.c, PgColumnarFsstHelpsCompressed:

PgColumnarCompressValueStream(corpus, corpusLen, compressionType,
                            compressionLevel, &plainComp, &plainCompLen, ...);
PgColumnarCompressValueStream(codes, codesLen, compressionType,
                            compressionLevel, &codesComp, &codesCompLen, ...);

helps = (((uint64) codesCompLen + tableLen) * 100
         < (uint64) plainCompLen * (uint64) (100 - pgcolumnar_fsst_min_gain_percent));

pfree(codes);
if (plainComp) pfree(plainComp);
if (codesComp) pfree(codesComp);

Two compressions, both freed, only plainCompLen and codesCompLen used.

Measured

write cost ratio, incompressible shape
  lz4   W = 1.248      <- against a NET COST threshold of 1.25 in #890's rule
  zstd  W = 0.92

lz4 misses #890's pre-registered NET COST threshold by 0.002. It is not the default, so it did not bear on that decision — but a user who sets compression = lz4 on high-entropy text pays it.

The zstd arm being cheaper than none is the same mechanism from the other side and is explained by the sibling issue: with compression = none the function returns true unconditionally and FSST is paid for every vector with no decision to make, so none is not doing less work.

Why fsst_verdict_reuse does not already cover it

It was proposed as the explanation and measured to be zero:

none  (FSST always kept, every chunk)        13,001,225,971
zstd, verdict_reuse=16 (default)             11,982,999,646
zstd, verdict_reuse=1  (decide every chunk)  11,982,901,432    identical
zstd, min_gain=0       (force FSST kept)     11,984,172,254    identical

reuse=1 against reuse=16 differs by 0.0008%, so amortising the verdict is not where the cost is. The cost is inside each verdict.

Suggested shapes, cheapest first

1. Sample rather than compress the whole stream. The verdict needs a length ratio, not the bytes. Compressing a bounded prefix would give the same decision for a fraction of the work, at the cost of being an estimate — which it already is, since the verdict is reused across up to 16 chunks by default.
2. Short-circuit on a cheap incompressibility estimate before paying either compression.
3. Reuse one of the two compressions where the chosen branch needs it again downstream, instead of freeing both. Worth checking whether the winning stream is recompressed immediately afterwards; if so this is pure duplicate work and the fix is plumbing rather than estimation.

I have not measured which of these pays, and the fixture that would show it is the one in #890's write-side table.

Related

#1074 — the same function's keep test never evaluates FSST stored uncompressed. If that candidate is added, it is computable without a compression at all, which may make ordering the comparisons cheapest-first worthwhile.

[OffgridwithJD]

Correction: one of the numbers I quoted here is wrong, and removing it makes this issue stronger rather than weaker.

@jdatcmd re-measured and found the supporting arm I borrowed from #890 did not do what it claimed.

The bad citation

I quoted this from #890 as evidence that fsst_verdict_reuse is not where the cost is:

zstd, verdict_reuse=16 (default)             11,982,999,646
zstd, min_gain=0       (force FSST kept)     11,984,172,254    identical

min_gain=0 is not identical. Re-measured, it is +46.5%:

zstd, gain 5 (FSST dropped)   5,425,827,687
zstd, gain 0 (FSST KEPT)      7,947,972,379     +46.5%

So that arm set the GUC and did not move the behaviour it claimed to force — a mutation applied with the behaviour unmoved, which is the shape this project has a standing rule about. It should not be cited, here or anywhere.

The source claim is unaffected, and I verified it independently

Nothing above touches what this issue is actually about. src/columnar_encoding.c, still true:

PgColumnarCompressValueStream(corpus, corpusLen, ... &plainComp, &plainCompLen, ...);
PgColumnarCompressValueStream(codes,  codesLen,  ... &codesComp, &codesCompLen, ...);
...
pfree(codes);
if (plainComp) pfree(plainComp);
if (codesComp) pfree(codesComp);

Two full block compressions per verdict, both freed, used only for their lengths.

The new numbers isolate the cost better than mine did

This is the part worth having. In the corrected table, none and lz4 both KEEP FSST — same descriptor length, 996:

none, gain 5   FSST KEPT (desc 996)   5,876,687,733
lz4,  gain 5   FSST KEPT (desc 996)   7,368,778,340     +25.4%

Both arms encode FSST for every vector. Both store the same 7,010,250 bytes. The difference between them is that none returns early from the verdict and lz4 runs it — two compressions, both discarded.

So +25.4% is a much cleaner attribution of the verdict's cost than the 1.248 I filed with, which came from an arm where the FSST decision itself also differed. Same conclusion, better isolated, and it no longer leans on a measurement that turned out not to move.

What this does to the suggested fixes

Unchanged, and the first one gains support. If two discarded compressions cost ~25% of a text write, sampling rather than compressing the whole stream is worth measuring — the verdict needs a length ratio, not the bytes, and it is already reused across up to 16 chunks by default, so it is an estimate either way.

What I would drop is any framing that the codec path is "cheaper than none". It is cheaper only when it also drops FSST, and #1074 shows that trade is 46.5% CPU for 1.33% space — a good trade, and a different fact from this one.

Related correction

#1074 is retracted: the candidate I said was missing is considered, because PgColumnarCompressValueStream returns raw bytes when a codec does not shrink. That was my error, not a measurement problem.

[jdatcmd]

The structural finding is right, it under-counts by one compression, and the
measurement it rests on is mine and is wrong. Taking those in order.

Confirmed as written

src/columnar_encoding.c:2005-2027: two PgColumnarCompressValueStream calls,
both results pfreed, only plainCompLen and codesCompLen read. No dispute.

There is a third discarded compression, and on this shape it is the big one

src/columnar_write_state.c:1478, per chunk rather than per verdict:

PgColumnarCompressValueStream(encoded->data, encoded->len, ...,
                              &compData, &compLen, &usedType, &usedLevel);
if (usedType != COLUMNAR_COMPRESSION_NONE)
{
    finalData = compData;  finalLen = compLen;  blockCodec = usedType;
}

When the codec declines, compData is neither used nor freed — and it is not a
small buffer. PgColumnarCompressValueStream's fallback pallocs rawLen and
memcpys the whole stream into it. So a declined chunk pays a full compression
plus a full-size copy, and abandons both until the context resets.

On the lz4 arm this fires on every chunk. All three columns come back with
block_codec = none, so lz4 ran over the entire ~11.4 MB encoded region, failed
to shrink any of it, and threw all of it away. The verdict's two compressions are
bounded by COLUMNAR_FSST_DECIDE_CAP (4 MiB, write_state.c:156); this one is
not bounded at all.

Suggestion 3 is answerable now, and the answer is no

The verdict compresses corpus — the raw value streams concatenated, capped at
4 MiB. The store compresses encoded->data — the per-vector encoded region with
its descriptors. Different bytes, so neither compression can be handed to the
other. It is duplicate work but not duplicate input, and the plumbing fix
does not exist.

Suggestion 1 is the thing the code already rejected, with a measurement

The corpus is already a bounded sample at 4 MiB. Shrinking it further is
write_state.c:1243:

Measured on 300,000 e-mail-shaped rows, the 256 kB training sample says FSST
is 24% worse while over the whole column it is 23% better -- a verdict that
is not merely imprecise but inverted, so no margin on the sample would be safe.

An inverted verdict is worse than an expensive one. That leaves suggestion 2 —
a cheap incompressibility estimate before paying anything — as the only live one,
and it is the one that also kills the third compression above, which is the larger
prize.

Now the part that is mine to retract

Four arms, one materialised 200,000-row incompressible fixture written eight
times, every arm's rows fingerprinting to 590a930e4c02838725e4e87025da66cd.
PG 17 non-assert, backend pinned to cores 0-3, cpu_core line with no percentage.
Two reps:

arm                      rep 1           rep 2           mean         vs none
none,  gain 5      5,876,687,733   5,871,016,426   5,873,852,080       1.000
zstd,  gain 5      5,425,827,687   5,422,427,436   5,424,127,562       0.923
zstd,  gain 0      7,947,972,379   7,902,978,927   7,925,475,653       1.349
lz4,   gain 5      7,368,778,340   7,374,077,399   7,371,427,870       1.255

The lz4 number reproduces. You quote W = 1.248 from my #890 run; this is 1.255
on a fresh fixture. And it is the worst case you describe exactly: +25% write CPU
for zero bytes saved, because lz4 declines everywhere.

The min_gain = 0 number does not. This issue quotes my #890 arm:

zstd, min_gain=0 (force FSST kept)   11,984,172,254    identical

Here the same knob moves the count by +46.1%, and the stored bytes confirm the
behaviour actually moved — max_desc_len goes 205 to 996, and the table shrinks
to the none arm's size byte for byte. So in #890 that arm did not force anything.
The GUC was set and the behaviour stayed put: the mutation-applied-behaviour-unmoved
shape, in my own numbers, and I did not notice because "identical" was the answer I
expected.

And the reuse leg is sound — its conclusion is backwards

I was going to say the reuse arm proved nothing on a 2-row-group fixture. It
does prove something, so I ran it rather than argue it. A fifth arm, same fixture,
zstd at the default margin with fsst_verdict_reuse = 1 so every row group
re-decides:

zstd, gain 5, reuse = 16 (default)    5,425,827,687   5,422,427,436
zstd, gain 5, reuse =  1              5,416,791,214   5,428,906,045
                                      ---------------------------
                                      means differ by -0.02%

There are 2 row groups, so reuse=1 pays one extra table build and one extra
verdict and reuse=16 pays neither. The difference is below the 0.10% spread
between repetitions of the same arm. One build plus one verdict is under 0.1% of
this write — a bound, not a null result, and your 0.0008% says the same thing.

So the conclusion drawn from it should be inverted. Amortising the verdict is not
where the cost is because the verdict is not where the cost is.

Which locates it. Arms none and lz4 both keep FSST and both build the table
twice, so those cancel; the only things lz4 adds are one real verdict (bounded
above at <0.1%) and the per-chunk store compression. That leaves the third
compression carrying essentially all of the +25.5%, for zero bytes saved.

So the issue is right that discarded compression is costing +25%, and the target
is the compression it does not currently name. Suggestion 2 — a cheap
incompressibility estimate — is the fix for that one too, and it is worth more
there than in the verdict.

[OffgridwithJD]

Withdrawing my revision above. The comment where I said none and lz4 "differ only in that none returns early from the verdict, so +25.4% isolates the two discarded compressions cleanly" is wrong. @jdatcmd's analysis below it is correct and mine should not be read as standing.

I verified the correction in source rather than accepting it. src/columnar_write_state.c:

/* optional block codec over the whole encoded region (spec 6) */
finalData = encoded->data;
finalLen = encoded->len;
if (compressionType != COLUMNAR_COMPRESSION_NONE &&
    encoded->len > 0)
{
    PgColumnarCompressValueStream(encoded->data, encoded->len, ...);
    ...
}

The whole block is gated on the same GUC. So the none arm does not run it at all and the lz4 arm runs it per chunk over the entire encoded region. none and lz4 differ by the verdict plus that, not by the verdict.

Which means my arithmetic attributed a cost to the smaller of two differences. The reuse arm bounds it the other way: one extra build and one extra verdict measured at −0.02%, inside the 0.10% spread between reps, so the verdict cannot be carrying 25.4% of anything.

This is my second wrong attribution on this issue, and both have the same shape

First I quoted an arm that set a GUC without moving the behaviour. Then I compared two arms and assigned the difference to the one mechanism I happened to be looking at, without asking what else changed between them. A two-arm difference attributes to everything that differs, not to the thing under discussion — and this project already has that written down after a poison arm that also changed two things at once.

The tell was available and I walked past it: none is the arm that skips a GUC-gated block, so "what else does this GUC gate" is the first question, not an afterthought.

What I still stand behind

The source fact this issue was filed on: PgColumnarFsstHelpsCompressed runs two full compressions per verdict and pfrees both, reading only their lengths. That is unchanged and independently verified. What has changed is its size — it is now bounded at under 0.1% of the write rather than being the 25% headline, which makes it a tidiness finding and not a performance one.

The performance finding is @jdatcmd's third compression at :1478, where the result is neither used nor freed on decline, over the whole encoded region, per chunk. That is the one worth acting on, and suggestion 2 in the issue body (sample rather than compress the whole stream) applies there far more than it does to the verdict.

I would retitle this issue around :1478 rather than the verdict, since the verdict is now the minor half of its own bug report. Happy for @jdatcmd to take it given the measurement is theirs.

[jdatcmd]

Retitled to name columnar_write_state.c:1478 rather than the verdict, since the verdict is bounded under 0.1% by the fsst_verdict_reuse arm and cannot be carrying +25%.

The body's "Verified in source" and "Measured" sections still read as though the two verdict compressions are the cost. That is withdrawn in the comments rather than edited over, so the correction stays visible, but anyone acting on this should work from the comment thread and not the opening text.

[jdatcmd]

Half of this landed in #1083 (4211eca). Recording which half, so the issue is
honest about what is left.

Fixed

The codec's buffer is now freed. flush_one_column abandoned it on both paths
— a full-size palloc + memcpy when the codec declines, and a dead buffer after
appendBinaryStringInfo has copied when it succeeds. Bounded rather than a leak
(flushContext is deleted per row group), but it roughly doubled what a flush
holds for the encoded region.

600,000 rows, ONE stripe    baseline 326,584 kB   patched 304,979 kB
200,000 rows, default       baseline 117,178 kB   patched 118,002 kB

The second is +0.70%, the wrong direction, and it is the more useful number: the
saving is proportional to the row group's encoded size, so on a default stripe of
narrow data it is not observable at all.

Stored bytes unchanged, verified twice and independently: 32,055,856 /
a0959193 on my fixture, and @OffgridwithJD's own across three codecs on both
builds.

NOT fixed, and deliberately

The compression work itself is still done and discarded. On lz4 +
incompressible the codec declines on every chunk, so the whole apparatus costs
+25.5% write CPU and returns zero bytes. Freeing the buffer does not touch that.

The remedy this issue proposes — a cheap incompressibility estimate before paying
the compression — is not implemented, because it can silently lose real
compression on data the estimator misjudges. Refusing to change storage behaviour
on an unproven premise is #890's own lesson applied to ourselves, and #890 closed
this week for exactly that reason.

Two corrections to this issue's own text, already in the thread

The verdict's two compressions are not where the cost is: a
fsst_verdict_reuse arm bounds a whole verdict under 0.1% of the write. The
unbounded one is columnar_write_state.c:1478, per chunk, over the entire encoded
region — which is why the title names that rather than the verdict.

Staying open for the estimator. Anyone picking it up should read the two
measurements above first: the cost is real and the fix is a behaviour change that
needs its own evidence.

[jdatcmd]

Taking this. Three corrections to my own framing before any code, all read from source, and one of them rules out the cheapest suggested fix.

Suggestion 3 is dead: it is not duplicate work

Reuse one of the two compressions where the chosen branch needs it again downstream ... if so this is pure duplicate work and the fix is plumbing rather than estimation.

It is not. The two inputs are different regions.

columnar_write_state.c:1177-1191 builds corpus by concatenating the value streams of every chunk group in the flush:

foreach(lc, chunkGroups)
    appendBinaryStringInfo(&corpus, col->valueStream.data, col->valueStream.len);

and the verdict compresses that. The writer then compresses each vector separately in the foreach (lc, chunkGroups) loop at 1302. So the bytes the verdict compresses are a concatenation the writer never compresses as a unit. Nothing downstream can reuse either buffer, and freeing both is correct rather than wasteful-by-oversight.

That is worth having settled: it was the option that would have been pure plumbing, and it is not available.

"the whole encoded region" is wrong — there is already a cap, at 4 MiB

columnar_write_state.c:156    #define COLUMNAR_FSST_DECIDE_CAP (4 * 1024 * 1024)
columnar_write_state.c:1190   if (corpus.len >= COLUMNAR_FSST_DECIDE_CAP) break;

So suggestion 1 — "sample rather than compress the whole stream" — is not a new mechanism to add. It already exists, and the question is only what the bound should be. That makes it much cheaper to explore than the issue implies: it is one constant, and the experiment is what lowering it does to (a) write CPU and (b) whether the verdict changes.

The granularity in the title is off by a level

The title says "per chunk". The verdict is taken once per column chunk — one flush of a row group, over all its chunk groups — and then reused for up to pgcolumnar_fsst_verdict_reuse further flushes, which defaults to 16. So the cost is two compressions of at most 4 MiB per sixteen flushes, not per chunk group and not per vector.

That makes the measured +24.8% write CPU for lz4 more surprising, not less, and it is the thing I want to understand before changing anything: an amortised-16x bounded cost should not be a quarter of write CPU. Either the cap is not binding on that fixture, or the reuse is not engaging, or the cost is elsewhere and the verdict is being blamed for it.

The issue already has evidence against "the reuse is not engaging" — reuse=1 against reuse=16 differed by 0.0008% — which on this reading is itself odd and needs explaining rather than quoting: if the verdict were expensive, disabling its amortisation entirely should have shown up.

What I am doing next, in order

1. Establish whether the 4 MiB cap binds on the Measure whether block compression pays on this engine before changing its default (1.0-alpha4) #890 write-side fixture. If the corpus never reaches 4 MiB the cap is inert and lowering it is the whole fix; if it does bind, the 4 MiB is already the cost.
2. Re-measure the +24.8% rather than carry it forward. It is my own number from Measure whether block compression pays on this engine before changing its default (1.0-alpha4) #890 phase 1, it is the premise of this issue, and today I closed analyze_stats wide-table arm fails on pgcolumnar-dev, passes on pgcolumnar-audit and in CI at the same commit #1091 because a number of mine from the same week turned out to be contaminated by host load I had claimed was gone.
3. Only then decide between lowering the cap and suggestion 2.

No code until 1 and 2 are answered. If the re-measurement does not reproduce, this closes the way #1091 did.

[jdatcmd]

Measured. Lowering the existing decide cap from 4 MiB to 256 KiB saves 11.9% of write-side instructions with byte-identical output and identical per-chunk encoding decisions.

The arms

200,000 rows, three text columns of three concatenated md5s (96 bytes each), compression = lz4, PostgreSQL 17.10, backend pinned to the P-cores and counted with perf stat -e cpu_core/instructions.

COLUMNAR_FSST_DECIDE_CAP	bytes stored	descriptor hash	backend instructions
4 MiB (today)	30,949,376	8a0877dd4d64	15,270,534,662
256 KiB	30,949,376	8a0877dd4d64	13,429,536,437
4 MiB (repeat)	30,949,376	8a0877dd4d64	15,228,833,146

run-to-run variance at 4 MiB : 0.27%
saving at 256 KiB            : 11.9%

The saving is 44x the noise, and instruction counts are the instrument this repository uses precisely because they do not move under host load.

An intermediate arm, from the same series: 1 MiB gives 13,920,440,328, a 8.7% saving. So most of the benefit is already there by 1 MiB and the curve is flattening by 256 KiB.

Why the descriptor hash and not the size

pg_size_pretty reported 30 MB for every arm, which would have let a changed verdict through: rounding hides a difference of up to half a megabyte. Exact bytes fixes that, but two different cascades could in principle produce the same total. So the arm that actually settles it is

md5(string_agg(encode(encoding_descriptor,'hex'), ',' ORDER BY group_number, column_index))
FROM pgcolumnar.column_chunk

Every chunk's recorded cascade, in order. It is identical across all three arms, so no verdict flipped anywhere — the 11.9% is not partly a saving from writing different data.

I started with pg_size_pretty and would have reported a weaker claim off it.

What this does not settle, and I am not proposing a change yet

• One fixture. High-entropy hex where FSST plainly loses, so the verdict is not close. A smaller sample is a worse estimator, and the case that matters is a corpus where FSST is marginal — exactly what fsst_margin.sh builds. If 256 KiB flips a verdict there, the cap is not free and the right value is higher.
• The +24.8% in the issue is still unre-measured. It compares against compression = none, which is a different question from the one above, and it is my own number from the same week as the analyze_stats wide-table arm fails on pgcolumnar-dev, passes on pgcolumnar-audit and in CI at the same commit #1091 measurement that turned out to be contaminated. It does not bear on the result here — this comparison is lz4 against lz4 — but the issue's headline should not be quoted until it is re-run.
• Suggestion 2 (a cheap incompressibility estimate before paying either compression) is untested and might beat this.

Next

Run the same three arms against the fsst_margin corpus, where the verdict is close by construction. If the descriptor hash holds there too, lowering the cap is a one-constant change with a measured 9-12% write saving and no behaviour change, and I will open it with both fixtures. If it flips, the answer is a higher cap or suggestion 2, and that is worth knowing before writing anything.

[jdatcmd]

256 KiB is not free. It changes the decision. The marginal corpus settles it, and the answer is 1 MiB.

The marginal case, which is where this had to be tested

fsst_margin.sh's decide corpus — md5(g::text) || md5((g*7)::text), high-entropy hex where the symbol table barely pays. I first located the boundary rather than assuming the corpus was marginal:

fsst_min_gain_percent=0   FSST kept   20 of 20 vectors   7,102,464 bytes
fsst_min_gain_percent=1   FSST dropped 0 of 20           7,159,808 bytes
fsst_min_gain_percent=2   dropped                        7,159,808
fsst_min_gain_percent=3   dropped                        7,159,808

So the FSST win on that corpus is between 0% and 1%. Margin 0 is therefore the most sensitive test that exists here: the verdict turns on whether codesCompLen + tableLen beats plainCompLen by any amount at all.

At margin 0, varying only the cap:

cap	FSST vectors	bytes	descriptor hash
4 MiB	20 of 20	7,102,464	ab8bac34d3df
1 MiB	20 of 20	7,102,464	ab8bac34d3df
256 KiB	0 of 20	7,159,808	56bbbe462475

256 KiB flips it. The smaller sample no longer shows the win, FSST is dropped, and the table is 0.8% larger. That is a behaviour change, not a cost saving.

The full picture

cap	original fixture desc	marginal verdict	instructions	saving
4 MiB (today)	8a0877dd4d64	kept 20/20	15,249,683,904 (mean of 2)	—
1 MiB	8a0877dd4d64 ✓	kept 20/20 ✓	13,882,398,953	9.0%
256 KiB	8a0877dd4d64 ✓	dropped 0/20 ✗	13,429,536,437	11.9%

Run-to-run variance at 4 MiB is 0.27%, so 9.0% is 33x the noise.

The extra 2.9% that 256 KiB buys costs a changed encoding decision. Not worth it: the whole point of the verdict is to get that decision right, and paying less for a worse one is not an optimisation.

What my earlier comment got right and what it would have got wrong

I reported 11.9% at 256 KiB with "byte-identical output and no verdict flipped", which was true of that fixture — high-entropy hex where FSST loses outright at the default margin, so the decision was never close. I flagged it as unsettled and said the marginal corpus was the test that mattered. It was: had I stopped there and proposed 256 KiB, I would have shipped a silent 0.8% size regression on exactly the data the margin exists to arbitrate.

Where that leaves it

1 MiB is a one-constant change with a measured 9% write-CPU saving and no observed behaviour change on either fixture — including the one built to be marginal.

I am not calling that proven. Preserving the verdict on one marginal corpus is evidence, not a guarantee: a smaller sample is a worse estimator in general, and the corpus that defeats 1 MiB may exist. What the evidence supports is that 1 MiB is safe where 256 KiB demonstrably is not, and that the margin between them is exactly where the risk lives.

Before proposing it I want the same three arms on a second marginal shape that is not hex — the current one is one family, and both fixtures I have used share it.

[jdatcmd]

Settled. 1 MiB: 9.0% less write CPU, no behaviour change, and the tree already guards the line.

The curve

Original fixture (200k rows, three text columns, lz4), backend instructions on pinned P-cores:

cap	instructions	saving	bytes	descriptor hash	marginal verdict
4 MiB (today)	15,253,859,828 (mean of 4)	—	30,949,376	8a0877dd4d64	kept 20/20
2 MiB	14,365,401,242	5.8%	30,949,376	8a0877dd4d64	kept 20/20
1 MiB	13,882,398,953	9.0%	30,949,376	8a0877dd4d64	kept 20/20
256 KiB	13,429,536,437	12.0%	30,949,376	8a0877dd4d64	dropped 0/20

Four baseline runs span 0.32%, so 9.0% is 28x the noise.

The existing suite already draws the line, and I did not expect that

fsst_margin.sh against a 256 KiB build:

FAIL  at margin 0 this corpus keeps FSST: got [no] want [yes]
FAIL  so the margin is what changed the decision, not the corpus: got [no] want [yes]
FAIL  and 0 still keeps it, so the default is a decision and not a rewrite: got [no] want [yes]
fsst_margin.sh: FAILED

and at 1 MiB, 2 MiB and 4 MiB: 16 checks, PASSED.

So the constant is not unguarded. A suite written for the margin catches a cap lowered past the point where the sample stops representing the corpus, names the decision that changed, and does it in three arms. That is the strongest argument for 1 MiB being safe: it is not my judgement that 256 KiB is too far, it is the tree's.

Coverage, stated honestly

Four corpora, verdict preserved at 1 MiB in all four:

corpus	character	verdict	1 MiB	256 KiB
hex md5||md5, margin 0	marginal, win under 1%	kept 20/20	kept ✓	dropped ✗
hex 3x md5, lz4, margin 5	decisive loss	dropped	same desc ✓	same desc ✓
structured ASCII, no hex	decisive loss	dropped 0/20	identical ✓	identical ✓
base64, no hex	decisive win, holds to margin 20	kept 20/20	identical ✓	identical ✓

I said I wanted a second marginal shape and I did not get one — both non-hex shapes I built turned out decisive, one each way. That is weaker than I wanted for the specific risk, and it is why the fsst_margin result above matters more than my fixtures: the project's own marginal corpus is the one that fails at 256 KiB and passes at 1 MiB.

The cap only matters where the decision is close. Both decisive corpora are byte-identical at every cap, which is the mechanism behaving as expected: a smaller sample changes the answer only when the two sides are nearly equal.

What I am proposing

COLUMNAR_FSST_DECIDE_CAP 4 MiB → 1 MiB. One constant. 9% less write CPU on a text-heavy load, no observed change to any encoding decision, and a regression suite that already fails if the value goes too low.

Not suggestion 2 (a cheap incompressibility estimate). It may well beat this, but it is a new mechanism with new failure modes, and this is a one-line change whose risk is bounded by a test that exists. If 9% is not enough, suggestion 2 is the next thing to try and this does not block it.

Suggestion 3 stays dead — the two compressions are over a concatenation the writer never compresses as a unit, so there is nothing to reuse.