A pgcolumnar.analyze() could read one column instead of all, and take null_frac and bounds exactly from zone maps

[jdatcmd]

The problem

ANALYZE on a wide columnar table decodes every column, because the table-AM analyze
callbacks are never told which columns were asked for. Measured on 300,000 rows over 20
columns (one int, nineteen text of 80 bytes), analysing one column:

	columnar	heap
ANALYZE w (k)	622 ms	92 ms

6.8x slower on the shape columnar storage should win.

The cheap fix does not work, and this is worth recording

The obvious repair is to make the analyze slot lazy, reusing the deferred-slot
machinery already used for index fetch, and let ANALYZE's own per-column access drive
the projection. It buys nothing. acquire_sample_rows does:

rows[numrows++] = ExecCopySlotHeapTuple(slot);      /* analyze.c:1273, and again at 1294 */

It copies the whole tuple into a heap tuple and computes per-column statistics
afterwards, so every column is materialised at sample time regardless. Knowing the
column list would not help either: even ANALYZE w (k) samples full tuples. That is
a core design, not an oversight, and it is why an AM-side projection cannot fix this.

What a function could do that core cannot

Two things, and the second is the more interesting one.

1. Read one column at a time. Statistics are per attribute. A function can scan
each analysed column independently, which is exactly the access pattern the storage is
built for.

2. Take some statistics exactly, from metadata, without reading data at all. Zone
maps already hold per chunk null_count, value_count, and min/max. So:

• null_frac is exact, not sampled;
• the low and high bounds a range estimate depends on are exact;
• n_distinct and most_common_vals still need sampling, so this is a hybrid rather
  than a replacement.

That is better statistics, not merely cheaper ones, and it is a genuine advantage of
columnar storage rather than a workaround.

Writing the results is supported on 18+, and not before

Checked on all three majors rather than assumed:

function	PG17	PG18	PG19
pg_restore_attribute_stats	absent	present	present
pg_restore_relation_stats	absent	present	present
pg_clear_attribute_stats	absent	present	present

So on 18 and later this writes statistics through a documented API. On 15 to 17 it
would mean writing pg_statistic directly, which is a materially different risk
(stakind slot layout, stavalues typing, staop/stacoll correctness) and a real
version-support decision rather than a detail. My inclination is 18+ only, and to
say so plainly rather than ship a fragile catalog writer for older majors.

The catch that should decide this

Autoanalyze will not call it. Same shape as pgcolumnar.vacuum(), but the
consequence differs in kind: a stale vacuum wastes space, while stale statistics
silently produce bad plans. We would be handing users a fast path that quietly rots,
and the failure mode is a query that got slower for no visible reason.

See #415, which proposes a background worker to schedule exactly this class of work.
If that lands, this becomes considerably more attractive, because the scheduling
gap is the main objection.

What I would do first, before building anything

Measure whether scan_analyze_next_tuple itself can be made competitive, because
that is the path autoanalyze actually takes. The slice-based group sampling is already
there; the open question is whether 622 ms against heap's 92 ms is inherent to decoding
whole groups for scattered sampled rows, or whether there is slack in it.

That measurement decides what this issue is. If the AM path can be brought close to
heap, a separate function is a maintenance burden with a stale-statistics footgun
attached. If it cannot, the function is the only route to statistics that match what
the storage can cheaply provide.

Proposed shape, if it goes ahead

pgcolumnar.analyze(rel regclass, columns text[] DEFAULT NULL)

Core ANALYZE stays the correctness path and keeps working with autoanalyze. This is
an opt-in accelerator for wide tables, documented as needing scheduling, exactly as
pgcolumnar.vacuum() is.

Found while answering how the table-AM interface's lack of projection support is
solved. See also #413, which is the same root cause on the index-build path and is
fixable, because that callback is told which columns it needs.

[jdatcmd]

Recording that writing pg_statistic directly on 15 to 17 is viable, not deciding to do it

The issue above says a direct catalog writer for 15 to 17 is "materially different
risk". That is true of getting the values right and false of the mechanism, and the
distinction is worth having written down before it is lost. This is knowledge capture,
not a proposal.

The target has not moved in five majors

pg_statistic's shape, read off running servers rather than assumed:

major	columns
15.18	31, starelid ... stavalues5
17.10	identical
18.4	identical
19beta2	identical

Same 31 columns, same order, and the same five stakind values in use on all four.
A writer targeting this is not chasing a moving structure, which is the usual reason
catalog manipulation ages badly.

Core's own implementation is the specification

pg_restore_attribute_stats on 18+ is core doing exactly this, and its source is
src/backend/statistics/attribute_stats.c, 1,033 lines. The write itself is about
twenty:

static void
upsert_pg_statistic(Relation starel, HeapTuple oldtup,
                    Datum *values, bool *nulls, bool *replaces)
{
    if (HeapTupleIsValid(oldtup))
    {
        newtup = heap_modify_tuple(oldtup, RelationGetDescr(starel), values, nulls, replaces);
        CatalogTupleUpdate(starel, &newtup->t_self, newtup);
    }
    else
    {
        newtup = heap_form_tuple(RelationGetDescr(starel), values, nulls);
        CatalogTupleInsert(starel, newtup);
    }
    heap_freetuple(newtup);
    CommandCounterIncrement();
}

Its includes are all ordinary and available to an extension: access/heapam.h,
catalog/indexing.h, utils/array.h, utils/lsyscache.h, utils/syscache.h,
statistics/statistics.h. Nothing backend-private is involved.

So a 15 to 17 path is a port, not an invention. That is the durable point: the work
is bounded by reading an existing file, and if we ever want it, we lift the
value-construction logic and drop the SQL-callable wrapper.

Where the actual risk lives

Not in the insert. In the values:

• stavalues is anyarray and must be built with the column's element type,
  typmod and collation. Wrong typing here is the one failure mode that is not merely a
  bad plan: the planner reads that array with the column's type assumptions.
• staop must be the right operator for the stakind (the ordering operator for
  histogram and MCV slots), via get_opfamily_member rather than guessed.
• stacoll must be the column's collation, or comparisons in the planner use the
  wrong one.
• stadistinct has a sign convention: positive is an absolute count, negative is
  the negated fraction of rows. Easy to get backwards and it produces plausible-looking
  wrong estimates rather than an error.
• CommandCounterIncrement() after the write, which core does and which is easy to
  omit.

That list is the reason to be careful, and it is also the reason core wrote 1,000 lines
around a 20-line insert.

Prior art

pg_dbms_stats has manipulated planner statistics this way in the wild for years, so
this is not a novel technique, and superuser-only catalog writes for statistics are an
established if specialised thing to do.

What I would still not do casually

Ship it as the default path on 15 to 17. A wrong write is silent: it produces bad plans
rather than an error, and it persists until the next ANALYZE. If it is ever built, it
wants a verification mode that computes the same statistics through core ANALYZE on a
copy and compares, rather than trusting the writer.

Filed here so the option survives even if this issue does not.

[jdatcmd]

Measured the gate: the floor, and how the cost scales. Both are stronger than this

issue currently claims.

This issue records what ANALYZE costs today but not what a projected implementation
would cost, which is the number that decides whether to build it. PG18, my container,
one in ten key values NULL.

	300k rows	3M rows
columnar ANALYZE w (20 cols)	830 ms	4,007 ms
columnar ANALYZE w (k) (1 col asked for)	653 ms	3,839 ms
heap ANALYZE wh (k)	260 ms	266 ms
floor: 1-column columnar table, same rows	25 ms	68 ms

The finding is the scaling, not the constant factor

Heap is flat: 260 ms to 266 ms for ten times the rows. ANALYZE samples a fixed
30,000 rows, so heap's cost barely depends on table size.

Ours is not: 830 ms to 4,007 ms. Sampling scattered rows means touching a number of
row groups that grows with the table, and decoding all twenty columns of each. So the
gap widens with scale rather than staying at a constant multiple:

• 300k rows: 2.5x slower than heap
• 3M rows: 14.4x slower

Straight-lining that (and it is extrapolation, not measurement) puts a 100M-row table
around two minutes per ANALYZE, on something autovacuum triggers on its own schedule.
That is an operational cost, not a benchmark curiosity.

The prize is large and the floor is below heap

68 ms against 3,839 ms is 56x, and it is 3.9x faster than heap rather than 14.4x
slower. The floor holds the same rows and therefore the same number of row groups, so it
isolates the per-column-width effect, which is the one a projected read removes.

Claim 2 confirmed, and it is better than "cheaper"

	300k	3M
sampled null_frac	0.100933	0.0973
zone-map null_frac	0.100000	0.100000
truth	0.100000	0.100000

The sample is off by 0.27 percentage points at 3M and the zone-map sum is exact. So the
function returns better statistics, not merely cheaper ones. That is the part worth
leading with, since "faster ANALYZE" alone is easy to defer and "correct null_frac for
free" is not.

Query, for anyone reproducing:

SELECT sum(null_count)::numeric / sum(value_count + null_count)
  FROM pgcolumnar.zone_map
 WHERE storage_id = (SELECT storage_id FROM pgcolumnar.storage
                      WHERE relation_oid = 'w'::regclass)
   AND column_index = 0 AND vector_index = -1;

One methodology note, because it nearly caught me

My first run reported ANALYZE on 3M rows at 12 ms, identical to the 300k figure.
Both impossible, and impossible in the same way, which is what gave it away: an INSERT
had a syntax error, 2>&1 swallowed it, the tables did not exist and every ANALYZE
failed instantly. A broken fixture reads as a spectacular result.

The probe now asserts its row counts before measuring and aborts if they are wrong. This
is the #418 shape in a different costume, and worth remembering when we build the real
suite for whatever comes of this.

Still not gated

I have not measured what ANALYZE costs when autovacuum drives it under concurrent
load, which is where the two-minute extrapolation would actually bite. Worth a bench run
before committing to build. @ChronicallyJD if you have bench time, that shape would
settle it.

[jdatcmd]

Two theories measured. The owner's is right in its essential form; mine is wrong in the

way I stated it.

3M rows, 20 columns, PG18, k with 45,000 distinct values and one in ten NULL. Table 27 MB,
index on k 20 MB.

=== baseline ===
  columnar ANALYZE w (all 20 cols) : 5,095 ms
  columnar ANALYZE w (k)           : 4,371 ms     <- asking for one column barely helps
  heap     ANALYZE wh (k)          :   336 ms

=== the index route ===
  count(DISTINCT k) via Index Only Scan : 18,134 ms
  GROUP BY k (MCV top-10) via the index :    308 ms
  min/max via the index                 :     16 ms

=== control: same work with NO index ===
  count(DISTINCT k) via a columnar scan :    498 ms

=== the floor ===
  1-column columnar table, same rows    :     88 ms

Correcting my own theory first

I said the AM path "has slack" because the cost is decoding the other nineteen columns, and
offered the 88 ms single-column floor as evidence. That evidence does not support the
claim I made. The floor is a table that has one column. It is not a projection of a
twenty-column table.

acquire_sample_rows calls ExecCopySlotHeapTuple, so core materialises every column
of every sampled row regardless of what was asked for. That is exactly why
ANALYZE w (k) costs 4,371 against 5,095: nearly nothing. The AM cannot decline to
produce columns core is about to copy.

So the 88 ms floor is evidence for a function, which can read one column, not for
fixing the AM path. Whatever slack the AM path has is in which row groups the sample
touches, not in column projection, and I have not measured that.

The owner's theory, tested properly

The essential claim holds: a sorted walk of the index gives the distribution without any
columnar decode.

• min/max: 16 ms. Btree endpoints. Effectively free.
• MCV and grouping: 308 ms, beating the columnar scan's 498 ms, because the index's
  sort order lets the aggregate stream instead of sorting.

But my count(DISTINCT) probe was a bad instrument and I nearly reported it as a
refutation. 18,134 ms is not what a sorted index walk costs; it is what
count(DISTINCT) costs when it sorts 3M rows it was handed one at a time. The same data
through GROUP BY on the same index is 59x faster. If we build this, the shape that
matters is the streaming sorted walk, not count(DISTINCT).

Where the two combine, and where the idea stops

Zone maps already give min/max and null_frac exactly, so the index is not needed for
those. What the index adds is n_distinct, MCVs and histogram bounds, from sorted data,
cheaply. That is precisely the gap I said still required sampling. The two are
complementary rather than overlapping.

The limit is unchanged and it is real: this only covers indexed columns. A twenty-column
table with one index still pays full freight for the other nineteen.

One result that weakens the "better statistics" argument

estimated n_distinct : 45,304      true: 45,000     0.7% off
estimated null_frac  : 0.099633    zone map: 0.100000 (exact)

Sampling got n_distinct to within 0.7% here. I previously leaned on exactness as a reason
to build this. On this fixture that argument is weak: the sample is already good. The
exactness is worth having, but it is not the case for the work. Speed is.

What I would now say the decision is

1. The 58x gap between 5,095 ms and an 88 ms single-column read is real, and a function is
   the only route to it, because core's sampling contract forecloses the AM route.
2. The index adds the distribution statistics that zone maps cannot, cheaply, for indexed
   columns only.
3. The stale-statistics objection is unchanged and remains the strongest argument against:
   autoanalyze will not call any of this. Future: a background worker to schedule columnar vacuum and analyze, which autovacuum cannot reach #415 is the answer, and this becomes much more
   attractive if that lands.

Still unmeasured: whether the AM path's group-access pattern has slack independent of
column count, and what any of this costs under concurrent autovacuum load.

[jdatcmd]

Isolated: extended statistics work correctly on columnar. The defect I suspected does

not exist, and the flakiness was PostgreSQL's MCV threshold.

I reported earlier in this thread that a columnar table appeared to ignore extended
statistics while heap benefited from them. That was wrong. Here is the isolation.

The result, with the confound removed

b = a*2 (perfect dependency), 300,000 rows, WHERE a = 5 AND b = 10, three runs each:

distinct values in a	heap estimate	columnar estimate	actual
10 (each 10% of rows)	28,970 / 29,510 / 31,190	30,480 / 30,310 / 29,840	30,000
1000 (each 0.1%)	1 / 1 / 1	1 / 1 / 1	300

Columnar tracks heap arm for arm. In this sample it is marginally the more accurate of the
two. There is no pgColumnar defect here.

The root cause of the readings that misled me

MCV-list membership. With 1,000 near-uniformly distributed values, a value must be
"more common than average" to enter the MCV list, and at 0.1% each they all sit on that
boundary. Whether a = 5 is captured is decided by the random ANALYZE sample. Inside, the
dependency has something to anchor to and the estimate lands around 370 to 430. Outside,
it does not, and the estimate falls to PostgreSQL's clamped floor of 1.

That is why the identical construction produced 370, then 430, then 1: three samples, not
three behaviours. Making the value unambiguously common makes it stable on both storage
types, which is the row above.

How I got it wrong, recorded because the shape recurs

My first probe read heap on a lucky sample and columnar on an unlucky one, in the same run,
and I read the difference as columnar-specific. Every subsequent explanation I proposed was
also wrong and each was refuted by the next measurement:

1. "The extraction method (FORMAT JSON with head -1) is at fault." Refuted: plain
   EXPLAIN and FORMAT JSON agree in every arm, and there is exactly one Plan Rows in
   the output, so head -1 was never wrong.
2. "CREATE STATISTICS and ANALYZE must be in the same call." Refuted: held twice, then
   failed on all three repetitions.
3. "It is columnar-specific." Refuted: heap shows identical behaviour under identical
   conditions.

Two observations agreeing is not a pattern. It took twelve arms on fresh tables to see it.

What this means for the idea that started the thread

The 1-against-300 row is the interesting one, and it is the case the owner raised: values
that fall just below the MCV threshold get a 300x underestimate, and nothing today decides
that those values deserve closer attention.

That is the gap a distribution-aware sampling strategy would fill, and the important
practical finding is that extended statistics are a working home for its output on a
columnar table, which was not established before today.

Worth a separate issue rather than more scope on this one.

[jdatcmd]

Split the distribution-aware sampling idea out to #438, so this issue stays about making ANALYZE cheap and that one is about making the statistics better where the planner is worst.

#438 carries the 300x underestimate measurement, the verified finding that extended statistics work on columnar tables (which had never been checked), and the three caveats that shape it: data frequency is not workload frequency, a biased sample must not be written as marginal statistics, and the zone maps may be a cheaper route than the index walk.

[ChronicallyJD]

Bench numbers you asked for, plus the premise nobody had closed

Taking this and #415. Ran the shape you flagged as ungated, and one measurement that
decides whether the function is worth building at all. PG18, bench box idle (0 foreign
CPU-bound processes), 3M rows, 20 columns (1 int k + 19 text), 1237 MB columnar /
2344 MB heap — a genuinely incompressible fixture, which matters, see the methodology
note at the end.

The premise: does a projected one-column read of a WIDE table actually work?

You correctly retracted the 88 ms floor as evidence for fixing the AM path, but the issue
still leans on it as evidence for the function — and it has the same flaw there: a table
that HAS one column is not a projection of one column out of twenty. Since #338 landed,
this is directly measurable. All serial (max_parallel_workers_per_gather = 0), plan
asserted non-parallel, aggregates chosen so they cannot be answered from metadata:

	serial
decode all 19 text cols (full-table read)	7,680 ms
ANALYZE w (20 cols)	6,302 ms
decode only k out of the 20-col table	268 ms
decode k from a dedicated 1-col table	171 ms
heap ANALYZE wh (k)	186 ms
zone-map null_frac + bounds, metadata only	11 ms

Projection holds: 268 ms against 7,680 ms, 29x, and within 1.6x of a dedicated
single-column table. So the premise is sound and the prize is real:

• 6,302 ms -> 268 ms = 23.5x for a function that reads one column.
• Against heap we go from 34x slower to 1.4x slower.

Your open question, answered: the AM path has no slack of the kind I hoped

I suspected ANALYZE re-decoded a row group per sampled row, which would have been fixable
AM-side by caching the decoded group across scan_analyze_next_tuple calls — no core
change, no function, no #415 dependency. Refuted. Rebuilding at
chunk_group_row_limit = 1000 (10x smaller groups):

groups of 10,000 rows : 6,466 ms
groups of  1,000 rows : 6,771 ms

Unchanged. Cost does not scale with group size, because a 30,000-row sample spread over the
table touches proportionally more groups when they are smaller — the decoded volume is
constant. Combined with ANALYZE w 6,302 ms being close to a full-table decode at 7,680 ms,
the model is simply: ANALYZE decodes essentially the whole table, every column, because
the sample touches every row group.

That closes the branch. Your central claim stands: core's ExecCopySlotHeapTuple contract
forecloses the AM route (ANALYZE w 6,302 vs ANALYZE w (k) 6,073 — asking for one column
saves 6%), and the group-access pattern has no exploitable slack either. A function is the
only route.

null_frac exactness reproduced

zone-map null_frac = 0.100000   (11 ms, no data read)
sampled  null_frac = 0.1014
truth              = 0.100000

Agreed with your later comment that this is a bonus rather than the case for building —
speed is the case, and 23.5x is the number.

Methodology, because I got this wrong three times before it worked

Three void controls, each of which produced a fast number I initially read as good news:

1. Fixture too compressible. 19 text columns built from md5((g%1000)::text) gave 1000
   distinct values; the columnar table compressed 300x to 15 MB against heap's 4,689 MB and
   everything sat in cache. The "must be slow" control read in 13 ms.
2. Metadata shortcut. count(), min() and max() are answered from zone maps without
   touching data, so a 1237 MB table "read" in 11 ms. Both read arms were metadata lookups.
3. Parallelism confound. The aggregates ran Workers Planned: 5 while ANALYZE is
   single-threaded. The tell was the 976 kB one-column table being slower than the same
   column out of the 1237 MB table (171 ms vs 67 ms) — it is under
   min_parallel_table_scan_size and ran serial.

Same shape as your 2>&1-swallowed INSERT: a broken probe reads as a spectacular result.
The final run asserts the plan is non-parallel and uses only decode-forcing aggregates.

One consequence for your earlier figures worth noting: your fixture was also highly
compressible (27 MB for 3M rows x 20 columns), so the absolute numbers there are measuring a
cached table. The ratios held up on an incompressible fixture, which is the part that
mattered.

Where I think this leaves #414 and #415

The circular dependency should be named and broken: this issue says it is gated on #415,
while #415 partly justifies itself by the existence of more manual maintenance including
this. Neither can go first on those terms.

My proposal: #414 ships opt-in with the documented staleness caveat, exactly as
pgcolumnar.vacuum() already does, and #415 later schedules it. 23.5x on wide-table
ANALYZE is worth having before a daemon exists, and the honest framing is the same one
pgcolumnar.vacuum() already carries.

Plan and TDD slices in my next comment. Nothing implemented yet — this is the gate.

[ChronicallyJD]

Correcting my own number: the function delivers 14.1x, not the 23.5x I posted

I have slices 1 and 2 working, and measuring the real implementation says my headline was
too generous. Correcting it before it gets quoted.

What I claimed above: "6,302 ms -> 268 ms = 23.5x for a function that reads one column."

What that actually compared: core ANALYZE against a bare projected read. The function
has to do more than read the column — it has to compute something from it. count(DISTINCT)
over 2.7M non-null values costs roughly another 170 ms on top of the 268 ms read.

Measured, on the same 3M x 20 / 1237 MB fixture:

	serial
core ANALYZE w (20 columns)	6,197 ms
core ANALYZE w (k)	5,804 ms
pgcolumnar.analyze(w, ARRAY['k'])	440 ms
heap ANALYZE wh (k) (earlier run)	186 ms

14.1x, not 23.5x. Against heap we go from 33x slower to 2.4x slower, which is the
comparison I would now lead with.

Values are exact, which is the part that came out as advertised:

ours:  null_frac=0.1        n_distinct=45001
truth: null_frac=0.100000   n_distinct=45001

Why the timing had to be measured rather than assumed

Every exactness assertion in the suite passes whether or not projection works.
count(DISTINCT k) returns 45001 if it reads one column or all twenty. Had projection not
survived plpgsql's EXECUTE format(...), the function would have been correct and slow, the
suite would have been fully green, and nothing in it could have caught that. So the wall
clock is a correctness check on the approach here, not a nice-to-have.

It does survive: 440 ms against a 6,197 ms whole-table sample is only reachable by reading
one column.

Where it stands

Slice 1 (null_frac, exact, from zone maps — metadata only, no data read) and slice 2
(n_distinct, exact, one column) are green: 8 checks, RED->GREEN proven on each, with premises
that fail if core's sampled value ever lands exactly on truth and makes a check vacuous.

Still to come: histogram bounds and MCVs from the same single-column sample (with the zone
maps' exact min/max as the endpoints), and the differential-against-core verification you
proposed — which is the one that catches a silent wrong write, since
pg_restore_attribute_stats takes VARIADIC "any" and quietly drops a mistyped argument
with only a WARNING.

One scoping correction while I am here: I had listed "exact min/max bounds from zone maps" as
a standalone slice. It is not implementable as one — pg_stats.histogram_bounds is an array
of ordered values, not a low/high pair, so exact endpoints are a modification to a sampled
histogram rather than a thing you can write on their own.

[ChronicallyJD]

Slice 3 plan, and a finding that partly undercuts one of this issue's headline claims

Slices 1 and 2 are green and rebased onto 065c208. Before writing slice 3 I want to put a
design finding in front of you, because it argues against something the issue leads with.

"Exact min/max from zone maps" is mostly subsumed by the read we already do

The issue's second claim is that zone maps give exact bounds without reading data. True, and it
is what slice 1 does for null_frac — genuinely metadata-only, 11 ms, no decode.

But bounds are different. Slice 2 already reads the whole column to compute n_distinct,
and once you have read it, exact min and max fall out of that read for free. Taking them from
the zone maps instead adds a second source of truth for a value we are already holding.

So the zone-map advantage is real for null_frac and largely illusory for bounds. It would
only pay for a column where we compute nothing else — and a column we collect no distribution
statistics for is one core would not have sampled either.

I do not think this weakens the issue; it sharpens it. The case is the 14.1x, and exactness is a
by-product. But the issue currently sells bounds-from-metadata as an independent benefit and I
do not think it survives contact with the implementation. Say if you read it differently — you
may have a case in mind where we would want bounds and nothing else.

The fixture problem I have to solve first

The existing k column is uniform over 0..45000, so core's 30,000-row sample almost certainly
hits both extremes and its bounds are already near-exact. A check asserting "ours is exact
where core's is not" would be flaky by construction on that data — it would pass or fail on
the luck of the sample, which is the shape you diagnosed on the extended-statistics thread
(three samples, not three behaviours).

So slice 3 needs a column where the extreme is genuinely rare: one outlier row in 500,000.
Core's sample misses it with near-certainty, ours cannot. That is also the case that matters in
practice — a range predicate above the sampled maximum is where the planner's estimate collapses.

Planned fixture addition:

skew int  -- CASE WHEN g = 1 THEN 1000000 ELSE g % 100 END

True max 1,000,000, sampled max ~99. A four-orders-of-magnitude gap is not a coin flip.

Slice 3, and what I split out

Slice 3: histogram_bounds. RED first: the last element must equal the true maximum, with
premises that the outlier exists and that core's upper bound is far below it.

Slice 3b: most_common_vals / most_common_freqs, split out to keep one seam per slice.
It carries a constraint worth naming now: core excludes MCVs from histogram_bounds.
Writing both without that exclusion produces statistics core would never emit and double-counts
those values in selectivity. That is exactly the class of silent-wrong-write your
pg_restore_attribute_stats caution was about, so it wants the differential harness landing
alongside it rather than after.

Nothing implemented yet — this is the plan and the seam.