Re: autovacuum next steps, take 2 - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: autovacuum next steps, take 2
Date
Msg-id 20070223162217.GA20242@alvh.no-ip.org
Whole thread Raw
In response to Re: autovacuum next steps, take 2  ("Jim C. Nasby" <jim@nasby.net>)
Responses Re: autovacuum next steps, take 2  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-hackers
Jim C. Nasby wrote:
> On Thu, Feb 22, 2007 at 10:32:44PM -0500, Matthew T. O'Connor wrote:

> > I'm not sure this is a great idea, but I don't see how this would result 
> > in large numbers of workers working in one database.   If workers work 
> > on tables in size order, and exit as soon as they catch up to an older 
> > worker, I don't see the problem.  Newer works are going to catch-up to 
> > older workers pretty quickly since small tables will vacuum fairly quickly.
> 
> The reason that won't necessarily happen is because you can get large
> tables popping up as needing vacuuming at any time.

Right.

We know that a table that needs frequent vacuum necessarily has to be
small -- so maybe have the second worker exit when it catches up with
the first, or when the next table is above 1 GB, whichever happens
first.  That way, only the first worker can be processing the huge
tables.  The problem with this is that if one of your hot tables grows
a bit larger than 1 GB, you suddenly have a change in autovacuuming
behavior, for no really good reason.

And while your second worker is processing the tables in the hundreds-MB
range, your high-update 2 MB tables are neglected :-(

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Simple Column reordering
Next
From: "Jim C. Nasby"
Date:
Subject: Re: timestamp subtraction (was Re: [SQL] formatting intervals with to_char)