Re: autovacuum next steps, take 2

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@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)