Re: Berserk Autovacuum (let's save next Mandrill)
От | Masahiko Sawada |
---|---|
Тема | Re: Berserk Autovacuum (let's save next Mandrill) |
Дата | |
Msg-id | CA+fd4k6DJVU-TzOedMsDmynz7O4fXd9ZNEd19HzCstk=X1PWYg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Berserk Autovacuum (let's save next Mandrill) (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: Berserk Autovacuum (let's save next Mandrill)
|
Список | pgsql-hackers |
On Wed, 11 Mar 2020 at 13:24, Laurenz Albe <laurenz.albe@cybertec.at> wrote: > > On Wed, 2020-03-11 at 12:00 +0900, Masahiko Sawada wrote: > > > > I have one question about this patch from architectural perspective: > > > > have you considered to use autovacuum_vacuum_threshold and > > > > autovacuum_vacuum_scale_factor also for this purpose? > > > > > > I am torn. > > > > > > On the one hand it would be wonderful not to have to add yet more GUCs > > > to the already complicated autovacuum configuration. It already confuses > > > too many users. > > > > > > On the other hand that will lead to unnecessary vacuums for small > > > tables. > > > Worse, the progression caused by the comparatively large scale > > > factor may make it vacuum large tables too seldom. > > > > I might be missing your point but could you elaborate on that in what > > kind of case you think this lead to unnecessary vacuums? > > If you have an insert-only table that has 100000 entries, it will get > vacuumed roughly every 20000 new entries. The impact is probably too > little to care, but it will increase the contention for the three > autovacuum workers available by default. The same is true for read-write table, right? If that becomes a problem, it's a mis-configuration and user should increase these values just like when we set these values for read-write tables. Regards, -- Masahiko Sawada http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: