ITAGAKI Takahiro wrote:
> Alvaro Herrera <alvherre@commandprompt.com> wrote:
>
> > Here is the autovacuum patch I am currently working with. This is
> > basically the same as the previous patch; I have tweaked the database
> > list management so that after a change in databases (say a new database
> > is created or a database is dropped), the list is recomputed to account
> > for the change, keeping the ordering of the previous list.
>
> I'm interested in your multiworkers autovacuum proposal.
>
> I'm researching the impact of multiworkers with autovacuum_vacuum_cost_limit.
> Autovacuum will consume server resources up to autovacuum_max_workers times
> as many as before. I think we might need to change the semantics of
> autovacuum_vacuum_cost_limit when we have multiworkers.
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. This way, the maximum use of IO resources by vacuum can
be easily determined and limited by the DBA; certainly much simpler than
the vacuum cost limiting feature.
> BTW, I found an unwitting mistake in the foreach_worker() macro.
> These two operations are same in C.
> - worker + 1
> - (WorkerInfo *) (((char *) worker) + sizeof(WorkerInfo))
Ah, thanks. I had originally coded the macro like you suggest, but then
during the development I needed to use the "i" variable as well, so I
added it. Apparently later I removed that usage; I see that there are
no such uses left in the current code. The "+ sizeof(WorkerInfo)" part
is just stupidity on my part, sorry about that.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
