Re: [HACKERS] pg_upgrade vs vacuum_cost_delay
От | Magnus Hagander |
---|---|
Тема | Re: [HACKERS] pg_upgrade vs vacuum_cost_delay |
Дата | |
Msg-id | CABUevEzMaR1cu-Gwocs4CxwhqSdXeFVR1Q_An3brgau-QmjH3w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_upgrade vs vacuum_cost_delay (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [HACKERS] pg_upgrade vs vacuum_cost_delay
Re: [HACKERS] pg_upgrade vs vacuum_cost_delay |
Список | pgsql-hackers |
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. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: