Re: Remaining case where reltuples can become distorted across multiple VACUUM operations

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Remaining case where reltuples can become distorted across multiple VACUUM operations
Date: 2022-08-08 15:25:54
Message-ID: CAH2-Wz=fFuyU3W7--XBKAHvhGEZB_V1Y7sqYL1NRQDKwQKQTEA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 8, 2022 at 8:14 AM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2022-08-08 15:33:44 Re: Remaining case where reltuples can become distorted across multiple VACUUM operations
Previous Message Ibrar Ahmed 2022-08-08 15:21:06 Get the statistics based on the application name and IP address