Re: Berserk Autovacuum (let's save next Mandrill)
От | Justin Pryzby |
---|---|
Тема | Re: Berserk Autovacuum (let's save next Mandrill) |
Дата | |
Msg-id | 20200316043424.GF26184@telsasoft.com обсуждение исходный текст |
Ответ на | Re: Berserk Autovacuum (let's save next Mandrill) (Laurenz Albe <laurenz.albe@cybertec.at>) |
Список | pgsql-hackers |
On Fri, Mar 13, 2020 at 10:48:27PM +0100, Laurenz Albe wrote: > On Fri, 2020-03-13 at 13:44 -0500, Justin Pryzby wrote: > > Possible it would be better to run VACUUM *without* freeze_min_age=0 ? (I get > > confused and have to spend 20min re-reading the vacuum GUC docs every time I > > deal with this stuff, so maybe I'm off). > > > > As I understand, the initial motivation of this patch was to avoid disruptive > > anti-wraparound vacuums on insert-only table. But if vacuum were triggered at > > all, it would freeze the oldest tuples, which is all that's needed; especially > > since fd31cd2651 "Don't vacuum all-frozen pages.", those pages would never need > > to be vacuumed again. Recently written tuples wouldn't be frozen, which is ok, > > they're handled next time. > > Freezing tuples too early is wasteful if the tuples get updated or deleted > soon after, but based on the assumption that an autovacuum triggered by insert > is dealing with an insert-mostly table, it is not that wasteful. You're right that it's not *that* wasteful. If it's a table that gets 90% inserts/10% updates, then only 10% of its tuples will be frozen. In the worst case, it's the same tuples every time, and that's somewhat wasteful. In the best case, those tuples are clustered on a small number of pages. -- Justin
В списке pgsql-hackers по дате отправления: