Re: autovacuum next steps, take 2
От | Jim C. Nasby |
---|---|
Тема | Re: autovacuum next steps, take 2 |
Дата | |
Msg-id | 20070227163020.GE29041@nasby.net обсуждение исходный текст |
Ответ на | Re: autovacuum next steps, take 2 (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: autovacuum next steps, take 2
|
Список | 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 по дате отправления: