On Tue, Feb 27, 2007 at 12:12:22PM -0500, Matthew T. O'Connor wrote: > Jim C. Nasby wrote: > >On Tue, Feb 27, 2007 at 12:00:41AM -0300, Alvaro Herrera wrote: > >>Jim C. Nasby wrote: > >> > >>>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. > >>Actually, I've been thinking that it would be a good idea to change the > >>semantics of autovacuum_naptime so that it means the average time to > >>start a worker in any given database. That way, the time between > >>autovac runs is not dependent on the number of databases you have. > > > >BTW, another issue that I don't think we can ignore: we actually need to > >do this on a per-tablespace level, or at least have the ability to > >disable or somehow limit it. While it's not common, there are users that > >run a hundred or more databases in a single cluster; it would be ugly if > >we suddenly had 100 vacuums trying to run on the same set of drives > >concurrently. > > I think we all agree that autovacuum needs to become tablespace aware at > some point, but I think that is further down the line, we're having > enough trouble figuring things out without that additional complication.
Sure, we just need a way to disable the multiple autovac daemon stuff then. -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
