Re: Berserk Autovacuum (let's save next Mandrill)
От | Laurenz Albe |
---|---|
Тема | Re: Berserk Autovacuum (let's save next Mandrill) |
Дата | |
Msg-id | 7c132215f0e947af7d9ccb7a340ad6e81b369c24.camel@cybertec.at обсуждение исходный текст |
Ответ на | Re: Berserk Autovacuum (let's save next Mandrill) (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Berserk Autovacuum (let's save next Mandrill)
Re: Berserk Autovacuum (let's save next Mandrill) |
Список | pgsql-hackers |
On Mon, 2020-03-16 at 14:34 -0700, Andres Freund wrote: > > > In particularl, I think it'd make sense to *not* have a lower freezing > > > horizon for insert vacuums (because it *will* cause problems), but if > > > the page is dirty anyway, then do the freezing even if freeze_min_age > > > etc would otherwise prevent us from doing so? > > > > I don't quite see why freezing tuples in insert-only tables will cause > > problems - are you saying that more WAL will be written compared to > > freezing with a higher freeze_min_age? > > As far as I understand the patch may trigger additional vacuums e.g. for > tables that have some heavily updated parts / key ranges, and otherwise > are largely insert only (as long as there are in total considerably more > inserts than updates). That's not at all uncommon. > > And for the heavily updated regions the additional vacuums with a 0 min > age could prove to be costly. I've not looked at the new code, but it'd > be particularly bad if the changes were to trigger the > lazy_check_needs_freeze() check in lazy_scan_heap() - it'd have the > potential for a lot more contention. I think I got it. Here is a version of the patch that does *not* freeze more tuples than normal, except if a prior tuple on the same page is already eligible for freezing. lazy_check_needs_freeze() is only called for an aggressive vacuum, which this isn't. Does that look sane? Yours, Laurenz Albe
Вложения
В списке pgsql-hackers по дате отправления: