Re: [HACKERS] pg_upgrade vs vacuum_cost_delay

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] pg_upgrade vs vacuum_cost_delay
Дата
Msg-id ZWDgAhPkTLCoqQlK@momjian.us
обсуждение исходный текст
Ответ на Re: [HACKERS] pg_upgrade vs vacuum_cost_delay  (Magnus Hagander <magnus@hagander.net>)
Список 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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: [HACKERS] pg_upgrade vs vacuum_cost_delay
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Questions regarding Index AMs and natural ordering