Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
Alvaro Herrera <[EMAIL PROTECTED]> 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.
+1
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
