From: "Rigmor Ukuhe" <rigmor.ukuhe@finestmedia.ee>
To: <pgsql-performance@postgresql.org>
Subject: Re: When to do a vacuum for highly active table
Date: Wed, 31 Aug 2005 00:25:44 +0300
Organization: Finestmedia
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcWtqCLO1Qji3rAwRQSxeM5zsbuD4QAAJ1CA
In-Reply-To: <20050830211356.48138.qmail@web31606.mail.mud.yahoo.com>
Message-Id: <20050830212545.5472718E718@linux.finestmedia.tv>


> -----Original Message-----
> From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-
> owner@postgresql.org] On Behalf Of Markus Benne
> Sent: Wednesday, August 31, 2005 12:14 AM
> To: pgsql-performance@postgresql.org
> Subject: [PERFORM] When to do a vacuum for highly active table
> 
> We have a highly active table that has virtually all
> entries updated every 5 minutes.  Typical size of the
> table is 50,000 entries, and entries have grown fat.
> 
> We are currently vaccuming hourly, and towards the end
> of the hour we are seeing degradation, when compared
> to the top of the hour.
> 
> Vaccum is slowly killing our system, as it is starting
> to take up to 10 minutes, and load at the time of
> vacuum is 6+ on a Linux box.  During the vacuum,
> overall system is goin unresponsive, then comes back
> once vacuum completes.

Play with vacuum_cost_delay option. In our case it made BIG difference
(going from very heavy hitting to almost unnoticed vacuuming.)

Hope it helps.

Rigmor Ukuhe

> 
> If we run vacuum less frequently, degradation
> continues to the point that we can't keep up with the
> throughput, plus vacuum takes longer anyway.
> 
> Becoming quite a pickle:-)
> 
> We are thinking of splitting the table in two: the
> part the updates often, and the part the updates
> infrequently as we suspect that record size impacts
> vacuum.
> 
> Any ideas?
> 
> 
> Thanks,
> Mark
> 
> -----------------
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster