Re: [HACKERS] pg_upgrade vs vacuum_cost_delay - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] pg_upgrade vs vacuum_cost_delay
Date
Msg-id ZXJsIsWDh62xbRIr@momjian.us
Whole thread Raw
In response to Re: [HACKERS] pg_upgrade vs vacuum_cost_delay  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Fri, Nov 24, 2023 at 06:20:28PM +0100, Magnus Hagander wrote:
> On Fri, Nov 24, 2023 at 5:34 PM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > On Fri, Nov 24, 2023 at 01:10:01PM +0100, Michael Banck wrote:
> > > Hi,
> > >
> > > On Fri, Nov 24, 2023 at 12:17:56PM +0100, Magnus Hagander wrote:
> > > > On Fri, Nov 24, 2023 at 11:21 AM Michael Banck <mbanck@gmx.net> wrote:
> > > > > On Wed, Nov 22, 2023 at 11:23:34PM -0500, Bruce Momjian wrote:
> > > > > > +     Non-zero values of
> > > > > > +     <varname>vacuum_cost_delay</varname> will delay statistics generation.
> > > > >
> > > > > Now I wonder wheter vacuumdb maybe should have an option to explicitly
> > > > > force vacuum_cost_delay to 0 (I don't think it has?)?
> > > >
> > > > That's exactly what I proposed, isn't it? :)
> > >
> > > You're right, I somehow only saw your mail after I had already sent
> > > mine.
> > >
> > > To make up for this, I created a patch that implements our propoals, see
> > > attached.
> >
> > This is already posssible with PGOPTIONS, so I don't see the need for
> > a separate option:
> >
> >         PGOPTIONS='-c vacuum_cost_delay=99' psql -c 'SHOW vacuum_cost_delay;'
> >         test
> >          vacuum_cost_delay
> >         -------------------
> >          99ms
> >         (1 row)
> >
> > Here is a patch which shows its usage.
> 
> Given how common this would be I think that's a pretty use-unfriendly
> way to do it. I'd vote for still adding it.

Patch applied to master.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: micro-optimizing json.c
Next
From: Tatsuo Ishii
Date:
Subject: Re: Row pattern recognition