Re: New IndexAM API controlling index vacuum strategies
От | Andres Freund |
---|---|
Тема | Re: New IndexAM API controlling index vacuum strategies |
Дата | |
Msg-id | 20210416001218.egl52ro4pmtepegh@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: New IndexAM API controlling index vacuum strategies (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: New IndexAM API controlling index vacuum strategies
|
Список | pgsql-hackers |
Hi, On 2021-04-14 21:30:29 -0700, Peter Geoghegan wrote: > I think that this was once true, but is now much less common, mostly > due to the freeze map stuff in 9.6. And due a general recognition that > the *risk* of increasing them is just too great (a risk that we can > hope was diminished by the failsafe, incidentally). As an example of > this, Christophe Pettus had a Damascene conversion when it came to > increasing autovacuum_freeze_max_age aggressively, which we explains > here: > > https://thebuild.com/blog/2019/02/08/do-not-change-autovacuum-age-settings/ Not at all convinced. The issue of needing to modify a lot of all-visible pages again to freeze them is big enough to let it be a problem even after the freeze map. Yes, there's workloads where it's much less of a problem, but not all the time. > As I said, we handle the case where autovacuum_freeze_max_age is set > to something larger than vacuum_failsafe_age is a straightforward and > pretty sensible way. I am curious, though: what > autovacuum_freeze_max_age setting is "much higher" than 1.6 billion, > but somehow also not extremely ill-advised and dangerous? What number > is that, precisely? Apparently this is common, but I must confess that > it's the first I've heard about it. I didn't intend to say that the autovacuum_freeze_max_age would be set much higher than 1.6 billion, just that that the headroom would be much less. I've set it, and seen it set, to 1.5-1.8bio without problems, while reducing overhead substantially. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: