Re: pg15: reltuples stuck at -1 after pg_upgrade and VACUUM

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Subject: Re: pg15: reltuples stuck at -1 after pg_upgrade and VACUUM
Date: 2023-08-09 13:18:14
Message-ID: 84941.1691587094@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Tue, Aug 8, 2023 at 8:43 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
>> The problem isn't that reltuples == -1 after the upgrade (which is
>> normal). The issue is that if VACUUM skips all the pages, it can leave
>> reltuples -1. My expectation is that after running "vacuum", no tables
>> are left in the "never have been vacuumed" state.

> But -1 isn't the "never have been vacuumed" state, exactly. At best it
> is the "never been vacuumed or analyzed" state.

Yeah. -1 effectively pleads ignorance about the number of live tuples.
If VACUUM has skipped every page, then it is still ignorant about
the true number of live tuples, so setting the value to something
else would be inappropriate.

Perhaps, though, there's a case for forcing all pages to be visited
if we start with reltuples == -1? I'm not sure it matters much
though given that you also need an ANALYZE run to be really in a
good place after pg_upgrade. The ANALYZE should update this.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2023-08-09 13:22:42 Re: Separate memory contexts for relcache and catcache
Previous Message Amit Langote 2023-08-09 12:56:56 Re: initial pruning in parallel append