> > >Yes, that's correct. Per previous discussion, what I actually wanted to > > >do was to create a GUC setting to simplify the whole thing, something > > >like "autovacuum_max_mb_per_second" or "autovacuum_max_io_per_second". > > >Then, have each worker use up to (max_per_second/active workers) as much > > >IO resources. > > One thing I forgot to mention is that this is unlikely to be implemented > in 8.3.
This is a WIP cost balancing patch built on autovacuum-multiworkers-5.patch. The total cost of workers are adjusted to autovacuum_vacuum_cost_delay. I added copy of worker's cost parameters to the shared WorkerInfo array. A launcher and each worker reads and writes the copied parameters when a worker starts a vacuum job or exit the process. Workers assign their local VacuumCostDelay from the shared value every sleep in vacuum_delay_point(). I agree that "mb_per_second" or "io_per_second" are easier to use than present cost delay parameters, but we need more research to move to it. I think it is better to keep "cost_limit" and "cost_delay" as of 8.3, but we need cost-balanced multiworkers at any rate. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
autovacuum_balance.patch
Description: Binary data
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
