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

Re: autovacuum next steps, take 2

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>,Hackers <pgsql-hackers(at)postgresql(dot)org>,Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>,Gregory Stark <stark(at)enterprisedb(dot)com>
Subject: Re: autovacuum next steps, take 2
Date: 2007-02-27 02:40:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Feb 26, 2007 at 08:11:44PM -0300, Alvaro Herrera wrote:
> Matthew T. O'Connor wrote:
> > Alvaro Herrera wrote:
> > >The second mode is the "hot table worker" mode, enabled when the worker
> > >detects that there's already a worker in the database.  In this mode,
> > >the worker is limited to those tables that can be vacuumed in less than
> > >autovacuum_naptime, so large tables are not considered.  Because of
> > >this, it'll generally not compete with the first mode above -- the
> > >tables in plain worker were sorted by size, so the small tables were
> > >among the first vacuumed by the plain worker.  The estimated time to
> > >vacuum may be calculated according to autovacuum_vacuum_delay settings,
> > >assuming that all pages constitute cache misses.
> > 
> > How can you determine what tables can be vacuumed within 
> > autovacuum_naptime?
> My assumption is that
> pg_class.relpages * vacuum_cost_page_miss * vacuum_cost_delay = time to vacuum

Need ta take vacuum_cost_limit into account.

The advantage to keying this to autovac_naptime is that it means we
don't need another GUC, but after I suggested that before I realized
that's probably not the best idea. For example, I've seen clusters that
are running dozens-hundreds of databases; in that environment you really
need to turn naptime way down (to like a second). In that case you
wouldn't want to key to naptime.
Jim Nasby                                            jim(at)nasby(dot)net
EnterpriseDB      512.569.9461 (cell)

In response to


pgsql-hackers by date

Next:From: Galy LeeDate: 2007-02-27 02:44:28
Subject: Re: Resumable vacuum proposal and design overview
Previous:From: Jim C. NasbyDate: 2007-02-27 02:37:34
Subject: Re: autovacuum next steps, take 2

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