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
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 |