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 0cd8685047ac86fdf9c5446a24ff3aed8755e290.camel@cybertec.at
Whole thread Raw
In response to Re: Berserk Autovacuum (let's save next Mandrill)  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: Berserk Autovacuum (let's save next Mandrill)
List pgsql-hackers
On Mon, 2020-03-02 at 14:57 +0100, I wrote:
> 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.

As a more substantial base for discussion, here is a patch that:

- introduces a GUC and reloption "autovacuum_vacuum_insert_limit",
  default 10000000

- introduces a statistics counter "inserts_since_vacuum" per table
  that gets reset to 0 after vacuum

- causes autovacuum to run without cleaning up indexes if
  inserts_since_vacuum > autovacuum_vacuum_insert_limit
  and there is no other reason for an autovacuum

No doc patch is included yet, and perhaps the new counter should
be shown in "pg_stat_user_tables".

Yours,
Laurenz Albe

Attachment

pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activityview?
Next
From: Fujii Masao
Date:
Subject: Re: Minor issues in .pgpass