Date: Wed, 24 Aug 2005 15:51:43 -0400
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Chris Hoover <revoohc@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Some ideas for comment
Message-ID: <20050824195143.GE17609@surnet.cl>
Mail-Followup-To: Chris Hoover <revoohc@gmail.com>,
	pgsql-performance@postgresql.org
References: <1d219a6f05082409563775a8a7@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1d219a6f05082409563775a8a7@mail.gmail.com>
User-Agent: Mutt/1.5.10i

On Wed, Aug 24, 2005 at 12:56:54PM -0400, Chris Hoover wrote:

> I don't have real numbers to give you, but we know that our systems
> are hurting i/o wise and we are growing by about 2GB+ per week (net). 
> We actually grow by about 5GB/week/server.  However, when I run my
> weekly maintenance of vacuum full, reindex, and the vacuum analyze, we
> end up getting about 3GB back.  Unfortunately, I do not have the i/o
> bandwidth to vacuum during the day as it causes major slowdowns on our
> system.  Each night, I do run a vacuum analyze across all db's to try
> and help.  I also have my fsm parameters set high (8000000 fsm pages,
> and 5000 fsm relations) to try and compensate.

[...]

> Right now, we are still on 7.3.4.  However, these ideas would be
> implemented as part of an upgrade to 8.x (plus, we'll initialize the
> new clusters with a C locale).

If you were on a newer version, I'd suggest that you use the cost-based
vacuum delay, and vacuum at least some of the tables more often.  This
way you can reduce the continual growth of the data files without
affecting day-to-day performance, because you allow the VACUUM-inflicted
I/O to be interleaved by normal query execution.

Sadly (for you), I think the cost-based vacuum delay feature was only
introduced in 8.0.

-- 
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
Officer Krupke, what are we to do?
Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke")