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 [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
