Message-ID: <4677DC06.3000300@metacarta.com>
Date: Tue, 19 Jun 2007 09:37:10 -0400
From: Karl Wright <kwright@metacarta.com>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-performance@postgresql.org
Subject: Re: Performance query about large tables, lots of concurrent
 access
References: <4676DD57.7070304@metacarta.com> <14291.1182221811@sss.pgh.pa.us>
	<4677B831.8060704@metacarta.com> <4677D298.2010109@metacarta.com>
	<20070619132643.GC4265@alvh.no-ip.org>
In-Reply-To: <20070619132643.GC4265@alvh.no-ip.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Alvaro Herrera wrote:
> Karl Wright wrote:
> 
>> This particular run lasted four days before a VACUUM became essential. 
>> The symptom that indicates that VACUUM is needed seems to be that the 
>> CPU usage of any given postgresql query skyrockets.  Is this essentially 
>> correct?
> 
> Are you saying you weren't used to run VACUUM all the time?  If so,
> that's where the problem lies.
> 

Postgresql 7.4 VACUUM runs for so long that starting it with a cron job 
even every 24 hours caused multiple instances of VACUUM to eventually be 
running in my case.  So I tried to find a VACUUM schedule that permitted 
each individual vacuum to finish before the next one started.  A vacuum 
seemed to require 4-5 days with this particular database - or at least 
it did for 7.4.  So I had the VACUUM schedule set to run every six days.

I will be experimenting with 8.1 to see how long it takes to complete a 
vacuum under load conditions tonight.

Karl