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

On Thu, Nov 12, 2026 at 8:00 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Thu, Nov 12, 2026 at 8:51 AM Melanie Plageman
> <melanieplageman(at)gmail(dot)com> wrote:
>
> > + if (old_rel_tuples < 0 || old_rel_pages == 0)
>
> Should this use old_rel_tuples <= 0?

This condition is meant to catch the case where pg_class.reltuples or
pg_class.relpages have not been changed from the defaults (-1 and 0
respectively). The test condition is the same as it previously was
if (old_rel_tuples < 0 || old_rel_pages == 0)
but with additional logic in the if statement.

> After DELETE followed by VACUUM (TRUNCATE false), an empty table can
> have reltuples = 0 and relpages > 0. After repopulating it, on-access
> pruning can mark most pages all-visible, and VACUUM can preserve the
> old zero estimate even though the table contains rows.

This case works the same as before the commits I made yesterday. The
first vacuum initializes reltuples and relpages, so the second vacuum
after repopulation doesn't hit the code block for when they are
uninitialized. The second vacuum scans too few pages to extrapolate
with and the number of pages hasn't changed, so it just uses the old
value. In this case, that's zero. Even if we did change the conditions
as you suggest, that would only allow it to set reltuples to -1,
meaning unknown. Vacuum hasn't scanned enough pages to make a new
estimate for reltuples.

- Melanie