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 ZWDgAhPkTLCoqQlK@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:
> > > 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.

Well, the big question is how many people have a non-default
vacuum_cost_delay, since it defaults to zero.  If someone has changed
the default (a small percentage), how many of those will be confused by
PGOPTIONS?  At that point, it seems unnecessary.  Also consider that a
new option will only be useful for those who have non-default
vacuum_cost_delay values, which can also be confusing.

-- 
  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: Magnus Hagander
Date:
Subject: Re: [HACKERS] pg_upgrade vs vacuum_cost_delay
Next
From: Peter Geoghegan
Date:
Subject: Re: Questions regarding Index AMs and natural ordering