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

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: Berserk Autovacuum (let's save next Mandrill)
Дата
Msg-id ade9403df7c3051ad68b58e98710c408511a4491.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: Berserk Autovacuum (let's save next Mandrill)  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: Berserk Autovacuum (let's save next Mandrill)  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
On Tue, 2020-03-17 at 14:56 -0500, Justin Pryzby wrote:
> I still suggest scale_factor maximum of 1e10, like
> 4d54543efa5eb074ead4d0fadb2af4161c943044
> 
> Which alows more effectively disabling it than a factor of 100, which would
> progress like: ~1, 1e2, 1e4, 1e6, 1e8, 1e10, ..
> 
> I don't think that 1e4 would be a problem, but 1e6 and 1e8 could be.  With
> 1e10, it's first vacuumed when there's 10billion inserts, if we didn't previous
> hit the n_dead threshold.
> 
> I think that's ok?  If one wanted to disable it up to 1e11 tuples, I think
> they'd disable autovacuum, or preferably just implement an vacuum job.

Assume a scale factor >= 1, for example 2, and n live tuples.
The table has just been vacuumed.

Now we insert m number tuples (which are live).

Then the condition

  threshold + scale_factor * live_tuples < newly_inserted_tuples

becomes

  10000000 + 2 * (n + m) < m

which can never be true for non-negative n and m.

So a scale factor >= 1 disables the feature.

Yours,
Laurenz Albe




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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Error on failed COMMIT
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: Berserk Autovacuum (let's save next Mandrill)