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

From Matthias van de Meent
Subject Re: Remaining case where reltuples can become distorted across multiple VACUUM operations
Date
Msg-id CAEze2Wh=W2oj+kvg_NzLpWWrhh8n+iVe_JNNrkuN2vGbkVCLgQ@mail.gmail.com
Whole thread Raw
In response to Re: Remaining case where reltuples can become distorted across multiple VACUUM operations  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Remaining case where reltuples can become distorted across multiple VACUUM operations
List pgsql-hackers
On Mon, 8 Aug 2022 at 16:52, Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Fri, Aug 5, 2022 at 5:39 PM Peter Geoghegan <pg@bowt.ie> wrote:
> > Attached patch fixes closes the remaining gap. With the patch applied,
> > the second and subsequent vacuum verbose operations from the test case
> > will show that reltuples is still 10000 (it won't ever change). The
> > patch just extends an old behavior that was applied when scanned_pages
> > == 0 to cases where scanned_pages <= 1 (unless we happened to scan all
> > of the relation's tables, of course).
>
> My plan is to commit this later in the week, barring objections. Maybe
> on Thursday.

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;

Kind regards,

Matthias van de Meent



pgsql-hackers by date:

Previous
From: Marcos Pegoraro
Date:
Subject: Re: bug on log generation ?
Next
From: Andrew Dunstan
Date:
Subject: Re: failing to build preproc.c on solaris with sun studio