FSST keep/drop is re-decided for every row group, though the answer rarely changes: cache the verdict with an age bound

[ChronicallyJD]

Recovered from an unvalidated stash before dropping it, so the idea and its measurement are not lost. Nothing here is gated, and the numbers below pre-date two mitigations that have since landed. Treat it as a lead to re-measure, not a finding.

The shape

pgcolumnar_flush_row_group decides FSST keep/drop once per row group:

• PgColumnarFsstBuildChunkTable (src/columnar_write_state.c:1094) builds the symbol table
• PgColumnarFsstHelpsCompressed (src/columnar_write_state.c:1115) decides whether to keep it

The decision cannot use a sample. The comment at the call site records why: on the sampled prefix FSST can look 12% worse while over the whole column it is 23% better, an inversion no margin on a sample would make safe. So asking the question costs a full FSST encode of the entire corpus, per row group.

For a column whose data does not change character, that recomputes the same answer for every row group of the load.

The measurement, as recorded at the time

Profiled on a 20,000,000-row numeric load, against a tree based on 0b6f24c (2026-07-29):

symbol	share of backend
encode_fsst_shared	34.8%
ColumnarFsstBuildChunkTable	17.7%

The verdict was "FSST does not help" every time, and the stored bytes were byte-identical either way. More than half the backend went to re-deriving a constant.

Re-measure before acting. That profile pre-dates both of these:

• PgColumnarFsstDictWins (Bulk load is 4.9x slower than heap, and import inherits it #155), a cheap distinct probe that skips the build when the dictionary wins outright. It does not touch the repeated whole-corpus decision, and it does not help the case here, where the dictionary does not win but FSST still loses consistently.
• pgcolumnar_fsst_min_gain_percent, which changed the threshold but not how often it is evaluated.

Whatever remains after those two is the real size of this.

The proposal

Cache the verdict on PgColumnarColumnDef and reuse it for a bounded number of row groups:

#define COLUMNAR_FSST_UNKNOWN   0
#define COLUMNAR_FSST_HELPS     1
#define COLUMNAR_FSST_HURTS     2
#define COLUMNAR_FSST_REUSE     16

int8    fsstVerdict;      /* COLUMNAR_FSST_* */
int     fsstVerdictAge;   /* row groups since the verdict was taken */

A HURTS verdict skips the build and the decision together. A HELPS verdict keeps the table without paying the whole-corpus encode again. The age bound is what keeps it honest: a column whose data changes character mid-load is still noticed, within COLUMNAR_FSST_REUSE row groups.

What has to be proven before this can land

The saving is real only if the stored bytes do not change. That is the whole risk: a stale verdict silently degrades compression, and nothing in the current suites would notice.

• A differential arm asserting byte-identical storage with the cache on and off, on a column where the verdict is stable.
• A fixture whose data changes character mid-load, asserting the verdict is re-taken within the bound and the storage matches the uncached result. Without this the age bound is untested and COLUMNAR_FSST_REUSE is a number nobody checked.
• The load-time win measured in-suite, not from a standalone probe.

Provenance

The stash also carried a COLUMNAR_FSST_MIN_GAIN_SHIFT margin, which is superseded: pgcolumnar_fsst_min_gain_percent does that job configurably. Only the caching is unlanded.

Original diff, 99 insertions across src/columnar_encoding.c and src/columnar_write_state.c, base 0b6f24c. It will not apply cleanly (the surrounding code has moved, and the symbols were renamed to the PgColumnar prefix by #389); it is a description of the approach, not a patch to apply.

[ChronicallyJD]

Re-measure before acting. That profile pre-dates both of these [PgColumnarFsstDictWins (#155) and pgcolumnar_fsst_min_gain_percent]. Whatever remains after those two is the real size of this.

Re-measured on current main (690c318), reproducing the numeric load this issue recorded rather than a corpus of my own choosing. Part of it went away and part of it did not, and the part that did not is the part this proposal removes.

symbol	recorded here (pre-mitigation)	current main, numeric load
encode_fsst_shared	34.8%	18.54%
PgColumnarFsstBuildChunkTable	17.7%	18.34%
pg_qsort	—	3.35%
fsst_count_add	—	2.33%
fsst_cand_cmp	—	1.17%

So encode_fsst_shared roughly halved — #155's distinct probe is doing real work — while the symbol-table build is unchanged. FSST-attributable frames still total about 44% of the backend.

That is the answer the issue asked for: the mitigations reduced the encode, not the repeated decision. Caching the verdict targets exactly the ~18% that did not move, plus the sort and counting that feed it.

Corroborated independently on a different corpus. Profiling an md5-text load through bench/run_profile.sh (#499) gives encode_fsst_shared 33.9% and PgColumnarFsstBuildChunkTable 14.6%, about 59% FSST-attributable. Different data, same shape.

How comparable these are

Worth stating so the table is not read as more precise than it is. The recorded profile was a 20,000,000-row numeric load on a tree based on 0b6f24c; mine is repeated 300,000-row inserts of (bigint, numeric(14,3), int) on 690c318, sampled for 10 seconds with cpu-clock and DWARF unwinding (9,992 samples). Same workload class, not the same fixture, and the percentages are shares of different totals.

The conclusion that survives that caveat is the relative one: within one profile, the build's share is where it was and the shared encode's is about half. That does not depend on the two runs being commensurable.

Two things I did not establish

The keep/drop verdict per chunk. This issue's case rests on the answer being the same every time, and I could not confirm it: pgcolumnar.column_chunk.encoding_descriptor is a packed bytea cascade rather than a readable label, so there is no cheap catalog query for "did this chunk keep FSST". Worth settling before building the cache, since a verdict that genuinely varies would make an age-bounded cache wrong rather than merely stale. If there is a decoder for the descriptor I missed, that is the check.

Why a numeric table spends 44% of its load in a string encoder at all. numeric is varlena, so attempting FSST on it is presumably legitimate rather than a bug, but the recorded verdict was "FSST does not help" every time on this shape. If that holds, the cache is not the only available answer here — declining to evaluate FSST for a column whose type has never benefited would skip the build outright rather than remembering its result. That may be a smaller change than the cache, or it may be wrong for reasons the write path knows and I do not; raising it as a question, not a counter-proposal.

Happy to take the cache implementation if you want it, now that it is sized.

[jdatcmd]

Claiming this (jdatcmd). Re-measured first, since the issue asks for that before anything else, and the old numbers pre-dated #155's probe and fsst_min_gain_percent.

The premise holds, on current main, after both mitigations

Instrumented build, one log line per column per row group, PG18.4, 2,000,000 rows per shape, stripe_row_limit => 100000 so 20 row groups:

shape	load	decisions	verdict	time deciding	share of load
md5(g)	5319 ms	20	hurts 20/20	2482 ms	47%
email-shaped	2081 ms	20	hurts 20/20	843 ms	41%
'label-' || (g%40)	533 ms	20	build skipped by #155	0 ms	0%
low-card then md5	3021 ms	10 built	hurts 10/10	1269 ms	42%

So 41 to 47 percent of a text load is spent re-deriving a verdict that never changes, and it is PgColumnarFsstHelpsCompressed rather than the table build: the whole-corpus FSST encode plus compress, once per row group. That is consistent with #499's independent profile (encode_fsst_shared 33.9%, PgColumnarFsstBuildChunkTable 14.6% on its ingest shape).

The low-cardinality row is worth reading too: #155's PgColumnarFsstDictWins is doing its job, skipping the build entirely, and that path costs nothing. This issue is about the other one.

The gap that would have made the tests vacuous

Every shape above returns hurts. A cache tested only on those would exercise one branch, and a HELPS verdict that was cached wrongly would sail through. So I went looking for a corpus where FSST actually wins, 600,000 rows each:

corpus	verdict
urls, emails, JSON, log paths, uuid-ish	hurts 6/6
'the quick brown fox ... number ' || g || ' in the morning'	helps 6/6

Long shared phrase with a varying number is the shape FSST is designed for, and it is the only one of six that wins. That gives the three proofs the issue demands a fixture each:

• stable HURTS: md5
• stable HELPS: the prose corpus
• character change mid-load: prose then md5, which flips HELPS to HURTS and is the only way to test the age bound rather than assume it

Design note, because it decides the test seam

The differential arm ("byte-identical storage with the cache on and off") needs an off switch, so this wants a GUC rather than a bare constant: pgcolumnar.fsst_verdict_reuse, default 16, 0 meaning always re-decide. That doubles as the escape hatch if a workload ever wants the old behaviour, and it is what the byte-identical arm compares against.

Implementing test-first from here.

[ChronicallyJD]

Correcting the numbers I posted above

The profile I sized this with was taken through two artifacts in bench/run_profile.sh, both found by jdatcmd in #504 and both mine:

• the ingest shape computed md5(g::text) inside the timed statement, so the fixture's own data generator was in the denominator every write-path percentage was measured against;
• the harness did not refuse an --enable-cassert build, which contributes self time that does not exist in production.

So the figures in my comment — encode_fsst_shared 18.54% and PgColumnarFsstBuildChunkTable 18.34% on current main — are directionally right and quantitatively wrong. With both artifacts removed the FSST share of the write path is far larger than I reported, and the corrected before/after is on #504.

The direction of my conclusion is unchanged and if anything strengthened: the mitigations reduced the encode and left the repeated decision alone, which is what this issue proposes to remove. But the size I gave it was understated, and #502's win is correspondingly larger than the number I attached to it.

Leaving the original comment in place rather than editing it, so the correction is legible rather than the record being quietly rewritten.