Re: Should the docs have a warning about pg_stat_reset()?

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Should the docs have a warning about pg_stat_reset()?
Date: 2019-03-27 23:49:02
Message-ID: CAKJS1f8HLSHMYgYqm5GtXUk9f9PV-Suy811CiJA2B0j8LxvoYA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 28 Mar 2019 at 10:33, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>
> On 2019-Mar-27, Peter Eisentraut wrote:
>
> > On 2019-03-26 16:28, Euler Taveira wrote:
> > > I don't remember why we didn't consider table without stats to be
> > > ANALYZEd. Isn't it the case to fix autovacuum? Analyze
> > > autovacuum_count + vacuum_count = 0?
> >
> > When the autovacuum system was introduced, we didn't have those columns.
> > But now it seems to make sense that a table with autoanalyze_count +
> > analyze_count = 0 should be a candidate for autovacuum even if the write
> > statistics are zero. Obviously, this would have the effect that a
> > pg_stat_reset() causes an immediate autovacuum for all tables, so maybe
> > it's not quite that simple.
>
> I'd say it would make them a candidate for auto-analyze; upon completion
> of that, there's sufficient data to determine whether auto-vacuum is
> needed or not. This sounds like a sensible idea to me.

Yeah, analyze, not vacuum. It is a bit scary to add new ways for
auto-vacuum to suddenly have a lot of work to do. When all workers
are busy it can lead to neglect of other duties. It's true that there
won't be much in the way of routine vacuuming work for the database
the stats were just reset on, as of course, all the n_dead_tup
counters were just reset. However, it could starve other databases of
vacuum attention. Anti-wraparound vacuums on the current database may
get neglected too.

I'm not saying let's not do it, I'm just saying we need to think of
what bad things could happen as a result of such a change.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2019-03-27 23:57:17 Re: amcheck verification for GiST
Previous Message David Rowley 2019-03-27 23:36:24 Re: Berserk Autovacuum (let's save next Mandrill)