Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Autovacuum loose ends

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>,pgsql-patches(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Autovacuum loose ends
Date: 2005-07-24 18:33:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> - pg_statistic is completely ignored.

... pg_statistic still needs vacuuming, surely.  It's only ANALYZE
that you can/should skip for it.

> - The postmaster's main loop sleeps Min(60, autovacuum_naptime), in
>   order to be able to pick naptimes smaller than 60 seconds.  In order
>   not to make the loop a busy-wait, I forced a minimum of 1 to that GUC
>   var.

Hmm, I wonder whether the minimum shouldn't be 10.  Or even 60.

> - Now that we have a real Xid wraparound check, we could go back to
>   having any table with no stat entry ignored, which was the original
>   coding.  There's no danger of wraparound, and there'd be no work done
>   to a table that doesn't have any activity.


>   We have to consider what
>   happens at stat reset -- AFAICS there's no problem, because as soon as
>   the table sees some activity, it will be picked up by pgstat.
>   However, it would be bad if stats are reset right after some heavy
>   activity on a table.  Maybe the only thing we need is documentation.

What's the use-case for having the stat reset feature at all?

> - datallowcon is still ignored.  Now it's safe to do so, because we have
>   a real Xid wraparound check.  Changing it requires extending the
>   pg_database flat-file (should be fairly easy).

I think this is all right, as long as a database that shows no stats
traffic is only connected to when it needs to be vacuumed for XID wrap
prevention purposes.

> - There are stat messages emitted for a database-wide vacuum, just like
>   any other.  This means that all tables in the database would end up in
>   pgstat; and also all databases, including those with datallowconn = false.
>   This may not be good.  I'm not sure what exactly to do about it.  Do
>   we want to disallow such stats?  Disable message sending (or
>   collecting) in some circumstances?

Needs thought...

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2005-07-24 18:36:14
Subject: Re: For review: Server instrumentation patch
Previous:From: Alvaro HerreraDate: 2005-07-24 18:21:25
Subject: Re: [HACKERS] Autovacuum loose ends

pgsql-patches by date

Next:From: Tom LaneDate: 2005-07-24 19:35:29
Subject: Re: Regression - GNUmakefile - pg_usleep
Previous:From: Alvaro HerreraDate: 2005-07-24 18:21:25
Subject: Re: [HACKERS] Autovacuum loose ends

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group