Re: autovacuum next steps, take 2
| От | Matthew T. O'Connor |
|---|---|
| Тема | Re: autovacuum next steps, take 2 |
| Дата | |
| Msg-id | 45E46676.9000809@zeut.net обсуждение исходный текст |
| Ответ на | Re: autovacuum next steps, take 2 ("Jim C. Nasby" <jim@nasby.net>) |
| Ответы |
Re: autovacuum next steps, take 2
|
| Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: