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)
|
Список | 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 по дате отправления: