analyze_function's null_frac premise fails ~1 run in 130: it requires core's sample to miss its own mode

[jdatcmd]

Hit on the full PG15-19 matrix run for #484, on PG19. No product code was at
fault; the suite failed itself, and it is right to, given how the check is
written. The check should not be written that way.

What happened

FAIL  premise: core's sampled null_frac differs from the truth, so this suite
      can discriminate: got [no (sample landed exactly on truth; suite is vacuous)]
-- core sampled null_frac = 0.1, truth = 0.100000

Every other check in the suite passed, including the one this premise guards
(pgcolumnar.analyze() reports null_frac exactly, from the zone maps).

Why it is not rare enough to ignore

test/analyze_function.sh:123 requires core's SAMPLED null_frac to differ from
the truth, so that "we are exact" is a claim core's number can disagree with.

The fixture is exactly one row in ten NULL, and core samples
300 * default_statistics_target = 30,000 rows. So the sampled NULL count is
binomial with n = 30,000 and p = 0.1, and the check demands that this binomial
not land on its own mode. Landing on 3000 exactly gives null_frac = 0.1,
which equals the truth, and that has probability

1 / sqrt(2 * pi * 30000 * 0.1 * 0.9)  ~=  0.8%

or roughly one run in 130. The suite runs on PG18 and PG19 and is skipped below
18, so that is two draws per matrix.

Measured on six consecutive PG19 runs after the failure, all six passed, with
core's sample at 0.099766664, 0.100833334, 0.10033333, 0.1041, 0.0987 and
0.09786667. The failure is the one draw that lands on the middle.

The same shape is already known here

#475 removed exactly this reasoning for the histogram outlier, and the note reads:

"core misses the outlier" cannot be a gate: it is probabilistic and depends
on our own sampler. Exactness is asserted against an independent
SELECT max() instead, which does not need core to be unlucky.

null_frac kept the old shape. n_distinct at line 168 has it too, though it is
far less exposed, since a sampled distinct estimate landing exactly on 45001 is
much less likely than a binomial landing on its mode.

Fix

Same remedy as #475. The exactness check already compares against an independent
SELECT over the table, so it does not need core to be wrong to mean something.
Either drop the premise to a printed note, or restate it as something that is
true by construction rather than by luck: for example, assert that core's number
came from a SAMPLE (that pg_stats was populated by ANALYZE at all), which is
the property the premise was really reaching for.

Do not "fix" it by loosening the comparison to a tolerance. The point of the
suite is exactness, and a tolerance would let a genuinely approximate result pass.

[ChronicallyJD]

Your diagnosis is right and the arithmetic checks out — 1/sqrt(2·pi·30000·0.1·0.9) = 0.00768, one run in 130. But I think the mode-landing is the symptom rather than the cause, and naming the cause gives a fix that is deterministic instead of merely less likely.

The cause is that the truth sits on the sample's lattice at all

Core's sampled null_frac is null_cnt / samplerows, and with default_statistics_target = 100 that denominator is 30,000. So core can only ever report a value from

{ m / 30000 : m = 0 .. 30000 }

The fixture is g % 10 = 0 over 500,000 rows — exactly 50,000 nulls — so the truth is 0.1, which is 3000/30000. It is a member of that set. The premise is not asking the binomial to avoid its mode as an unlucky coincidence; it is asking it to avoid one specific reachable point, and that point happens to be the most probable one.

Fix the lattice rather than the probability: choose a null count whose fraction core cannot express.

K/N · 30000 must not be an integer
K/500000 · 30000 = 3K/50, so K must not be a multiple of 50

50,000 is. 50,001 is not:

nulls	truth	×30000
49,999	0.09999800	2999.94	unrepresentable
50,000	0.10000000	3000.00	representable — today
50,001	0.10000200	3000.06	unrepresentable
50,050	0.10010000	3003.00	representable

One extra null row and no sample can land on the truth. Not 1 in 130 — never, by construction, which is what you asked the premise to be.

The real typing does not eat the margin. The gap between 0.1 and 0.100002 is 2.0e-6, and float4's spacing near 0.1 is about 7.5e-9, so the two are comfortably distinct:

f4(0.1)      = 0.1000000015
f4(0.100002) = 0.1000019982

Why I would not take the fix you proposed

Asserting "pg_stats was populated by ANALYZE at all" is true by construction, but it no longer guards anything: it would pass just as happily if core's sample were exact, which is the case that makes the check below it vacuous. It removes the flake by removing the premise's meaning.

The lattice version keeps the discriminating power — core still cannot be exact, and now cannot be exact deterministically — which is the property the premise was reaching for.

One thing to verify rather than assume

This rests on samplerows being exactly 30,000. acquire_sample_rows fills a reservoir of 300 * attstattarget and returns what it actually collected, which for a 500,000-row table should be the full 30,000 — but if it ever came back short the lattice changes and the guarantee goes with it. Worth reading the number out of the run rather than trusting the formula.

That also argues for asserting the property instead of hardcoding 0.100002, since PGC_ANALYZE_ROWS is overridable and a different ROWS can quietly put the truth back on the lattice:

# The premise, stated as the thing that makes it true: core's sample cannot
# express this fixture's null fraction, so "ours is exact and core's is not"
# cannot be satisfied by luck.
check "premise: core's 30,000-row sample cannot express the true null_frac" \
	"$(q "SELECT CASE WHEN (SELECT count(*) FILTER (WHERE k IS NULL)::numeric / count(*) FROM af_c)
	                      * 30000 = trunc((SELECT count(*) FILTER (WHERE k IS NULL)::numeric
	                                              / count(*) FROM af_c) * 30000)
	                 THEN 'representable (suite can pass by luck)' ELSE 'no' END")" "no"

n_distinct at line 168

Same treatment applies and is worth doing at the same time. You are right that it is far less exposed, but "less likely" is what this premise already was.

Overlap with #488

#488 renames the check this premise guards — it now reads "reports null_frac exactly, from reading the column" rather than "from the zone maps", because #485 moved null_frac off the zone maps and onto the same read as n_distinct. It does not touch the premise itself, so the two will conflict textually in that region but not semantically. Whichever lands first, I will rebase; no need to sequence them on my account.