Re: [BUG / PATCH] PG19: VACUUM misestimates reltuples (often 0) after on-access VM setting

Hello

+ /*
+ * With no prior density, a tiny non-random sample is not sufficient to
+ * estimate the relation's tuple count. This can happen when on-access
+ * pruning marks most pages all-visible before the first VACUUM.
+ */
+ if (old_rel_tuples < 0 || old_rel_pages == 0)
+ {
+ if (scanned_pages <= 1 ||
+ scanned_pages < (double) total_pages * 0.02)
+ return -1;
+
+ return floor((scanned_tuples / scanned_pages) * total_pages + 0.5);
+ }

and

stat->tuple_count = vac_estimate_reltuples(rel, nblocks, p.scanned,
+ p.scanned_new,
stat->tuple_count);

Is -1 a valid value for approx_tuple_count?

CREATE EXTENSION pgstattuple;
CREATE TABLE t (id int, pad text) WITH (autovacuum_enabled = off);
INSERT INTO t SELECT g, repeat('x', 100) FROM generate_series(1, 40000) g;
SELECT count(*) FROM t;
UPDATE t SET pad = 'y' WHERE id IN (1, 20000);
SELECT scanned_percent, approx_tuple_count FROM pgstattuple_approx('t');

Before 1a001d930ee (the already committed part) this shows
approx_tuple_count 35420 to me, after -1.

Without the UPDATE, it also returns -1 and already did so before, so
this is not entirely new, but I don't see this being mentioned
anywhere, and this suggests that it is unintended:

/* It's not clear if we could get -1 here, but be safe. */
stat->tuple_count = Max(stat->tuple_count, 0);