On Mon, 2007-07-23 at 12:00 -0400, Alvaro Herrera wrote: > Simon Riggs wrote: > > > The bad thing about having multiple autovacuum daemons active is that > > you can get two large VACUUMs running at the same time. This gives you > > the same small-VACUUM-starvation problem we had before, but now the > > effects of two VACUUMs kill performance even more. I would suggest that > > we look at ways of queueing, so that multiple large VACUUMs cannot > > occur. Setting vacuum_cost_delay will still allow multiple large VACUUMs > > but will make the starvation problem even worse as well. If we allow > > that situation to occur, I think I'd rather stick to autovac_workers=1. > > We will still have this potential problem even with HOT. > > We already discussed all this to death before feature freeze.
...and starvation has still not been avoided. I like what you have done, but we still have a problem, whichever release it gets fixed in. > I'm not > sure if it's a good idea to try to come up with new heuristics for the > thing this late. Feel free to work on it for 8.4 though! > > I also wonder whether you have noticed the "balancing" code in autovac. > Whenever more than one autovac workers are running, they split the > available I/O allocated to them fairly, so that each one delays more > frequently than if it was running alone. The net effect is supposed to > be that no matter how many workers are running, your vacuum delay > settings are respected. I did and I like it, many thanks. > In any case, I think a better solution to the starvation problem caused > by huge tables is not skipping the vacuuming of them, but making it less > wasteful, for example with the DSM. Neither of those things prevent starvation though. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings