Message-ID: <454917F7.3020901@zeut.net>
Date: Wed, 01 Nov 2006 16:56:07 -0500
From: Matthew O'Connor <matthew@zeut.net>
User-Agent: Thunderbird 2.0a1 (Windows/20060724)
MIME-Version: 1.0
To: Steven Flatt <steven.flatt@gmail.com>
CC: pgsql-performance@postgresql.org
Subject: Re: Database-wide vacuum can take a long time, during which
References: <357fa7590611011115q748ddce9qa6cf570ec2f15348@mail.gmail.com>
In-Reply-To: <357fa7590611011115q748ddce9qa6cf570ec2f15348@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Steven Flatt wrote:
> Here is a potential problem with the auto-vacuum daemon, and I'm 
> wondering if anyone has considered this.  To avoid transaction ID 
> wraparound, the auto-vacuum daemon will periodically determine that it 
> needs to do a DB-wide vacuum, which takes a long time.  On our system, 
> it is on the order of a couple of weeks.  (The system is very busy and 
> there is a lot of I/O going on pretty much 24/7).  During this period of 
> time, there is nothing to automatically analyze any of the tables, 
> leading to further performance problems.  What are your thoughts on 
> having the DB-wide vacuum running on a separate thread so that the 
> daemon can concurrently wake up and take care of analyzing tables?

Two issues here:
1)XID Wraparound:  There has been work done on this already, and in 8.2 
I believe there will no longer be a requirement that a database wide 
vacuum be issued, rather, XID wraparound will be managed on a per table 
basis rather than per database, so that will solve this problem.

2)Concurrent Vacuuming:  There has been a lot of talk about 
multiple-concurrent vacuums and I believe that this is required in the 
long run, but it's not here yet, and won't be in 8.2, hopefully it will 
get done for 8.3.


Matt