Re: autovacuum next steps, take 2 - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: autovacuum next steps, take 2
Date
Msg-id 20070227163020.GE29041@nasby.net
Whole thread Raw
In response to Re: autovacuum next steps, take 2  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: autovacuum next steps, take 2  ("Matthew T. O'Connor" <matthew@zeut.net>)
List pgsql-hackers
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.
-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: autovacuum next steps, take 2
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Developer TODO List as a PostgreSQL DB