Re: autovacuum multiworkers, patch 5
От | ITAGAKI Takahiro |
---|---|
Тема | Re: autovacuum multiworkers, patch 5 |
Дата | |
Msg-id | 20070409193116.879A.ITAGAKI.TAKAHIRO@oss.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: autovacuum multiworkers, patch 5 (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: autovacuum multiworkers, patch 5
Re: autovacuum multiworkers, patch 5 |
Список | pgsql-patches |
> > >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
Вложения
В списке pgsql-patches по дате отправления: