Date: Thu, 4 May 2006 08:27:47 -0400
From: Andrew Sullivan <ajs@crankycanuck.ca>
To: pgsql-performance@postgresql.org
Subject: Re: Postgres 7.4 and vacuum_cost_delay.
Message-ID: <20060504122747.GA21437@phlogiston.dyndns.org>
References: <DE02FD24E5A7504FA1D53631DA8CEA9BF8B62E@sottmxs10.entrust.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DE02FD24E5A7504FA1D53631DA8CEA9BF8B62E@sottmxs10.entrust.com>
User-Agent: Mutt/1.5.9i

On Tue, May 02, 2006 at 05:47:15PM -0400, Chris Mckenzie wrote:
> I've come to the conclusion I need to simply start tracking all transactions
> and determining a cost/performance for the larger and frequently updated
> tables without the benefit and penalty of pg_statio.

I'll bet it won't help you.  If you can't get off 7.4 on a busy
machine, you're going to get hosed by I/O sometimes no matter what. 
My suggestion is to write a bunch of rule-of-thumb rules for your
cron jobs, and start planning your upgrade.

Jan back-patched the vacuum stuff to 7.4 for us (Afilias), and we
tried playing with it; but it didn't really make the difference we'd
hoped.

The reason for this is that 7.4 also doesn't have the bg_writer.  So
you're still faced with I/O storms, no matter what you do.  If I were
in your shoes, I wouldn't waste a lot of time on trying to emulate
the new features in 7.4.

A

-- 
Andrew Sullivan  | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism. 
                --Brad Holland