Re: Berserk Autovacuum (let's save next Mandrill)
| От | Laurenz Albe |
|---|---|
| Тема | Re: Berserk Autovacuum (let's save next Mandrill) |
| Дата | |
| Msg-id | 98a1422dece118877ebbdc20cb78209f6d12866e.camel@cybertec.at обсуждение исходный текст |
| Ответ на | Re: Berserk Autovacuum (let's save next Mandrill) (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
| Ответы |
Re: Berserk Autovacuum (let's save next Mandrill)
|
| Список | pgsql-hackers |
On Tue, 2020-01-07 at 19:05 +0100, Tomas Vondra wrote: > This patch is currently in "needs review" state, but that seems quite > wrong - there's been a lot of discussions about how we might improve > behavior for append-only-tables, but IMO there's no clear consensus nor > a patch that we might review. > > So I think this should be either "waiting on author" or maybe "rejected > with feedback". Is there any chance of getting a reviewable patch in the > current commitfest? If not, I propose to mark it as RWF. > > I still hope we can improve this somehow in time for PG13. The policy is > not to allow new non-trivial patches in the last CF, but hopefully this > might be considered an old patch. I think that no conclusion was reached because there are *many* things that could be improved, and *many* interesting and ambitious ideas were vented. But I think it would be good to have *something* that addresses the immediate problem (INSERT-only tables are autovacuumed too late), as long as that does not have negative side-effects or blocks further improvements. I don't feel totally well with the very simplistic approach of this patch (use the same metric to trigger autoanalyze and autovacuum), but what about this: - a new table storage option autovacuum_vacuum_insert_threshold, perhaps a GUC of the same name, by default deactivated. - if tabentry->tuples_inserted exceeds this threshold, but not one of the others, lauch autovacuum with index_cleanup=off. How would you feel about that? Yours, Laurenz Albe
В списке pgsql-hackers по дате отправления: