Re: Should we increase the default vacuum_cost_limit?

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: Should we increase the default vacuum_cost_limit?
Дата
Msg-id 667136960c5b30a15c0250302b43e8707b003e43.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: Should we increase the default vacuum_cost_limit?  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: Should we increase the default vacuum_cost_limit?  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
David Rowley wrote:
> On Tue, 26 Feb 2019 at 02:06, Joe Conway <mail@joeconway.com> wrote:
> >
> > On 2/25/19 1:17 AM, Peter Geoghegan wrote:
> > > On Sun, Feb 24, 2019 at 9:42 PM David Rowley
> > > <david.rowley@2ndquadrant.com> wrote:
> > >> The current default vacuum_cost_limit of 200 seems to be 15 years old
> > >> and was added in f425b605f4e.
> > >>
> > >> Any supporters for raising the default?
> > >
> > > I also think that the current default limit is far too conservative.
> >
> > I agree entirely. In my experience you are usually much better off if
> > vacuum finishes quickly. Personally I think our default scale factors
> > are horrible too, especially when there are tables with large numbers of
> > rows.
> 
> Agreed that the scale factors are not perfect, but I don't think
> changing them is as quite a no-brainer as the vacuum_cost_limit, so
> the attached patch just does the vacuum_cost_limit.
> 
> I decided to do the times by 10 option that I had mentioned.... Ensue
> debate about that...
> 
> I'll add this to the March commitfest and set the target version as PG12.

I think this is a good move.

It is way easier to recover from an over-eager autovacuum than from
one that didn't manage to finish...

Yours,
Laurenz Albe



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: readdir is incorrectly implemented at Windows
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Remove Deprecated Exclusive Backup Mode