Re: Berserk Autovacuum (let's save next Mandrill)

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: Berserk Autovacuum (let's save next Mandrill)
Дата
Msg-id c3374108d853206e1cbc6b69aa5e697478e5bed7.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: Berserk Autovacuum (let's save next Mandrill)  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Berserk Autovacuum (let's save next Mandrill)  (Darafei "Komяpa" Praliaskouski <me@komzpa.net>)
Список pgsql-hackers
On Fri, 2020-03-13 at 09:10 +1300, David Rowley wrote:
> So you're suggesting we drive the insert-vacuums from existing
> scale_factor and threshold?  What about the 1 billion row table
> example above?

I am still not 100% certain if that is really realistic.
Transactions that insert only a single row are probably the
exception in large insert-only tables.

But I think that we probably always can find a case where any given
parameter setting is not so great, so in order to get ahead
let's decide on something that is not right out stupid.
Changing the defaults later is always an option.

So the three options are:

1. introduce no new parameters and trigger autovacuum if the number
   of inserts exceeds the regular vacuum threshold.

2. introduce the new parameters with high base threshold and zero scale factor.

3. introduce the new parameters with low base threshold and high scale factor.

I think all three are viable.
If nobody else wants to weigh in, throw a coin.

Yours,
Laurenz Albe




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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: Additional size of hash table is alway zero for hash aggregates