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