On Mon, Oct 23, 2006 at 03:08:03PM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > The only case I can think of where autovac might not work as well as > > smartvacuum would be if you had a lot of databases in the cluster, since > > autovacuum will only vacuum one database at a time. > > It's conceivable that it'd make sense to allow multiple autovac > processes running in parallel. (The infrastructure part of this is easy > enough, the hard part is keeping them from all deciding to vacuum the > same table.) It might be worth creating a generic framework that prevents multiple vacuums from hitting a table at once, autovac or not.
> One reason we have not done that already is the thought that multiple > vacuum processes would suck too much I/O to be reasonable. Now you > could dial back their resource demands with the cost-delay settings, > but it's not clear that ten autovacs running at one-tenth speed are > better than one autovac using all the cycles you can spare. Usually > I think it's best if a vacuum transaction finishes as fast as it can. There's other things that would benefit from having some idea on what IO resources are available. For example, having a separate bgwriter (or reader) for each set of physical volumes. So a means of grouping tablespaces wouldn't hurt. > In any case, these exact same concerns would apply to manual vacuums > or a combination of manual and auto vacuum. Well, the advantage to manual vacuums is that you can tune things to utilize multiple arrays... -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
