pgcolumnar.analyze(): exact null_frac, n_distinct and histogram_bounds (#414 slices 1-3)

[ChronicallyJD]

Slices 1-3 of #414. Slices 1 and 2 were already written and are here rebased onto current main; slice 3 is new.

slice	statistic	how
1	null_frac	exact, from zone maps, no decode
2	n_distinct	exact, from a single-column read
3	histogram_bounds	exact ends, from that same read

PG18+ only: it writes through pg_restore_attribute_stats, which 15-17 do not have. The suite skips below 18 rather than writing pg_statistic directly.

Slice 3

percentile_disc over an array of fractions returns actual column values, one per fraction, in a single ordered pass. Fraction 1.0 is therefore the true maximum and 0.0 the true minimum. percentile_cont would interpolate and invent values the column does not hold, which is wrong for a histogram of stored data and impossible for a non-numeric type.

That is the case that matters: a range predicate above the sampled maximum is where the planner's estimate collapses, and a value held by one row in 500,000 is one a 30,000-row sample misses.

Guarded to btree-orderable types, and skipped when the column has fewer distinct values than buckets, which is where core emits no histogram either.

What this slice does not claim. Core excludes most-common-values from the histogram. This function writes none, so there is nothing to double-count and the two are consistent as written. Writing both without that exclusion would over-count those values in selectivity, which is why most_common_vals is a separate slice rather than a line added here.

Two fixture findings that invalidated the plan I posted

The planned column cannot test this. g % 100 gives 100 distinct values, and core stores every one as a most-common-value and emits no histogram at all, so the check compared against an empty array and failed on its own premise rather than on the behaviour. The ordinary values now span 100,000 distinct.

"Core misses the outlier" cannot be a gate. It is probabilistic by definition, and it also depends on how our own access method hands rows to the sampler. Measured 99,999 on one run and 1,000,000 on the next, on identical data. Gating on it would be exactly the flaky-by-construction shape the fixture was built to avoid.

So it is reported, and exactness is asserted instead. The expected value comes from an independent SELECT max(), not from the code path under test, so the check still fails whenever our bounds are wrong. It does not need core to be unlucky.

The error check exists because I needed it

While writing the slice the function raised

ERROR:  record "att" has no field "atttypid"

and the redirect swallowed it. The call did nothing, pg_stats still held core's numbers, and the failure presented as "our maximum is wrong" rather than "our function did not run". The assertion caught it; the diagnosis needed the error. So the call's success is now a check of its own.

Gate

PG18  analyze_function   rc=0  checks run: 16  PASSED
PG18  harness_selftest   rc=0  checks run: 40  PASSED
PG19  analyze_function   rc=0  checks run: 16  PASSED
PG19  harness_selftest   rc=0  checks run: 40  PASSED

harness_selftest alongside because this registers analyze_function in the matrix for the first time; #473's sortedness and registration checks are what keep that honest.

Still open on #414, and named rather than implied

• slice 3b: most_common_vals / most_common_freqs, with the MCV-exclusion constraint above and a differential harness alongside it.
• the catch that should decide the feature: autoanalyze will not call this. Stale statistics silently produce bad plans, which is a worse failure than the stale-vacuum case. That is Future: a background worker to schedule columnar vacuum and analyze, which autovacuum cannot reach #415's territory and it is not resolved by this PR.
• The issue's headline "exact bounds from zone maps without reading data" is partly undercut, as recorded in the design comment on the issue: slice 2 already reads the whole column, so bounds fall out of that read for free. The zone-map advantage is real for null_frac and largely illusory for bounds.