Re: Berserk Autovacuum (let's save next Mandrill) - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: Berserk Autovacuum (let's save next Mandrill)
Date
Msg-id f04ff0a3a556c5578a95e335cc07f4fea1f7e247.camel@cybertec.at
Whole thread Raw
In response to Re: Berserk Autovacuum (let's save next Mandrill)  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Responses Re: Berserk Autovacuum (let's save next Mandrill)
Re: Berserk Autovacuum (let's save next Mandrill)
List pgsql-hackers
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.

Yours,
Laurenz Albe




pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: Re: [PATCH] Erase the distinctClause if the result is unique by definition
Next
From: Laurenz Albe
Date:
Subject: Re: [PATCH] Skip llvm bytecode generation if LLVM is missing