Re: Remaining case where reltuples can become distorted across multiple VACUUM operations - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Remaining case where reltuples can become distorted across multiple VACUUM operations
Date
Msg-id CAH2-Wz=fFuyU3W7--XBKAHvhGEZB_V1Y7sqYL1NRQDKwQKQTEA@mail.gmail.com
Whole thread Raw
In response to Re: Remaining case where reltuples can become distorted across multiple VACUUM operations  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: Remaining case where reltuples can become distorted across multiple VACUUM operations
List pgsql-hackers
On Mon, Aug 8, 2022 at 8:14 AM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
> I do not have intimate knowledge of this code, but shouldn't we also
> add some sefety guarantees like the following in these blocks? Right
> now, we'll keep underestimating the table size even when we know that
> the count is incorrect.
>
> if (scanned_tuples > old_rel_tuples)
>     return some_weighted_scanned_tuples;

Not sure what you mean -- we do something very much like that already.

We take the existing tuple density, and assume that that hasn't
changed for any unscanned pages -- that is used to build a total
number of tuples for the unscanned pages. Then we add the number of
live tuples/scanned_tuples that the vacuumlazy.c caller just
encountered on scanned_pages. That's often where the final reltuples
value comes from.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Ibrar Ahmed
Date:
Subject: Get the statistics based on the application name and IP address
Next
From: Matthias van de Meent
Date:
Subject: Re: Remaining case where reltuples can become distorted across multiple VACUUM operations