Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue) - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue)
Date
Msg-id 20221229012354.GF1153@telsasoft.com
Whole thread Raw
In response to Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Dec 28, 2022 at 03:13:23PM -0500, Tom Lane wrote:
> Peter Geoghegan <pg@bowt.ie> writes:
> > On Fri, Dec 16, 2022 at 6:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> That is a really good point.  How about teaching VACUUM to track
> >> the oldest original relfrozenxid and relminmxid among the table(s)
> >> it processed, and skip vac_update_datfrozenxid unless at least one
> >> of those matches the database's values?  For extra credit, also
> >> skip if we didn't successfully advance the source rel's value.
> 
> > Hmm. I think that that would probably work.
> 
> I'm forced to the conclusion that we have to expose some VACUUM
> options if we want this to work well.  Attached is a draft patch
> that invents SKIP_DATABASE_STATS and ONLY_DATABASE_STATS options
> (name bikeshedding welcome) and teaches vacuumdb to use them.

I was surprised to hear that this added *two* options.

I assumed it would look like:

VACUUM (UPDATE_DATABASE_STATS {yes,no,only})

-- 
Justin



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Avoiding unnecessary clog lookups while freezing
Next
From: Andres Freund
Date:
Subject: Re: windows/meson cfbot warnings