Re: First steps with 8.3 and autovacuum launcher - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: First steps with 8.3 and autovacuum launcher
Date
Msg-id 1191510180.4223.162.camel@ebony.site
Whole thread Raw
In response to Re: First steps with 8.3 and autovacuum launcher  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, 2007-10-04 at 10:43 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > I'd also like to see vacuum_delay_point() do a test against
> > CountActiveBackends() to see if anything else is running. If there all
> > non-autovac processes are idle or waiting, then we should skip the delay
> > point, this time only. That way a VACUUM can go at full speed on an idle
> > system and slow down when people get active again. It will also help
> > when people issue a DDL statement against a table that is currently
> > being vacuumed. I've got a patch worked out to do this.
> 
> This is exceedingly Postgres-centric thinking.  

Thanks :-)

> The lack of any other
> backends does not mean that the system owner wants Postgres to take over
> the machine.

Good thought. Sounds like we'd benefit from having another parameter:

autovacuum_vacuum_delay_siblings = -1 (default) 0..INT_MAX

Minimum number of active backends before autovacuum delay becomes
effective. If there are fewer than <param> active backends automatic
maintenance will proceed at full speed when the opportunity arises. The
delay will vary dynamically, thus utilising quiet periods more
effectively as and when they occur. Set to -1 if the database server is
running on a shared system and you do not want quiet periods to be used
for maintenance.

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Camilo Porto
Date:
Subject: What does 'elapsed' exact means in PostgreSQL Log Statistics
Next
From: Gregory Stark
Date:
Subject: Re: First steps with 8.3 and autovacuum launcher