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

From Jim C. Nasby
Subject Re: autovacuum next steps, take 2
Date
Msg-id 20070222142338.GP19527@nasby.net
Whole thread Raw
In response to Re: autovacuum next steps, take 2  ("Matthew T. O'Connor" <matthew@zeut.net>)
Responses Re: autovacuum next steps, take 2  ("Matthew T. O'Connor" <matthew@zeut.net>)
List pgsql-hackers
On Wed, Feb 21, 2007 at 05:40:53PM -0500, Matthew T. O'Connor wrote:
> My Proposal:  If we require admins to identify hot tables tables, then: 
> 1) Launcher fires-off a worker1 into database X.
> 2) worker1 deals with "hot" tables first, then regular tables.
> 3) Launcher continues to launch workers to DB X every autovac naptime. 
> 4) worker2 (or 3 or 4 etc...) sees it is alone in DB X, if so it acts as 
> worker1 did above.  If worker1 is still working in DB X then worker2 
> looks for hot tables that are being starved because worker1 got busy. 
> If worker2 finds no hot tables that need work, then worker2 exits.

Rather than required people to manually identify hot tables, what if we
just prioritize based on table size? So if a second autovac process hits
a specific database, it would find the smallest table in need of
vacuuming that it should be able to complete before the next naptime and
vacuum that. It could even continue picking tables until it can't find
one that it could finish within the naptime. Granted, it would have to
make some assumptions about how many pages it would dirty.

ISTM that's a lot easier than forcing admins to mark specific tables.
-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: What is CheckPoint.undo needed for?
Next
From: Andrew Dunstan
Date:
Subject: Re: SCMS question