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

On Fri, Nov 13, 2026 at 7:15 PM Lukas Fittl <lukas(at)fittl(dot)com> wrote:
>
> On Fri, Nov 13, 2026 at 2:13 PM Melanie Plageman
> <melanieplageman(at)gmail(dot)com> wrote:
>
> > Attached is what I propose doing and backpatching through 15.
>
> I haven't chimed in on this thread previously, but I assume that a
> review is still welcome to help get this addressed before GA.

Thanks for the review! Unfortunately, I didn't read this last night as
I hadn't much hope of getting replies and so I didn't get this in
before the freeze :( My bad.

> Reading back through the thread, and specifically this issue, I agree
> with your earlier sentiment that if we could, NULL or -1 is the better
> result here, but I see why we can't do that on the released back
> branches.

A quick LLM survey of other places we store or return counts of things
shows that while pg_class.reltuples is -1 when it doesn't have info
yet, SQL functions like pg_relation_size() return NULL when the table
is unavailable to get a size. Though cumulative stats counters that
are valid combinations but for which we don't yet have values are 0.

> Specifically, as someone who writes software that reads from
> statistics views and related functions in a Go program, suddenly
> getting NULL where it was an integer before would cause an error in
> the client program, so we shouldn't do that. I do think we should
> return NULL on master though, if we can - at least to me that's the
> most logical value.

It seems like NULL makes the most sense, as long as it isn't too
annoying for client programs.

> Theoretically, one could argue that we should fix this in 19 so we
> return NULL - its not a practical problem there in terms of breaking
> client programs (just yet), and the code change is small - but not
> sure if that is too much to ask for at this point.

Yea, I think we should change master only, so there is time to roll it
back before releasing it if people don't like it.

> Otherwise, +1 on the patch as is. I think the documentation change
> looks good as well.

I'll commit this specific patch after the 19 freeze is over to go out
with the next set of minors. Thanks again for the timely review and
apologies for not getting it out in time. I can then apply the change
to make it NULL on master afterward, assuming we think that's the
right thing to do.

- Melanie