DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
	b=demcLn4mAWrP4HPU8Be+TrWqGwo5FPeXwNCCxXuULakn2Zd+R1rEyzFuL/hCm335KqrZpWMeC9jwFAiXBa3EgbyzCPqR++NHMxNhkLoi5DzlufrDCEYGZlDwP+5Gb2SEuOO3Uz2kfnO63tjpfwwFv4cP8MSZOTDfb4QBomHk9D4=
Message-ID: <467AC48B.2050803@enterprisedb.com>
Date: Thu, 21 Jun 2007 19:33:47 +0100
From: Heikki Linnakangas <heikki@enterprisedb.com>
User-Agent: Icedove 1.5.0.10 (X11/20070329)
MIME-Version: 1.0
To: Steven Flatt <steven.flatt@gmail.com>
CC: pgsql-performance@postgresql.org
Subject: Re: Database-wide VACUUM ANALYZE
References: <357fa7590706211009w2ef6071fn83c5759db6be1e80@mail.gmail.com>
In-Reply-To: <357fa7590706211009w2ef6071fn83c5759db6be1e80@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Steven Flatt wrote:
> The bad thing, which I don't totally understand from reading the docs, is
> that another db-wide vacuum kicked off exactly 24 hours after the first
> db-wide vacuum kicked off, before the first one had finished.  (Note that
> these vacuums seem to go through the tables alphabetically.)  I managed to
> explain this to myself in that there were still rows in tables not yet
> touched by the first db-wide vacuum that could have XIDs older than
> autovacuum_freeze_max_age.  Fine, so two db-wide vacuums were now taking
> place, one behind the other.

Are you sure there's no cron job starting the vacuums? 24h sounds too 
good to be a coincidence, and there's no magic constant of 24h in the 
autovacuum code. Besides, autovacuum can only be running one VACUUM at a 
time, so there must be something else launching them.

What's your vacuuming strategy in general, before and after upgrade?

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com