Message-ID: <3B4CBC2C.53E8187B@postgresql.org>
Date: Thu, 12 Jul 2001 06:50:52 +1000
From: Justin Clift <justin@postgresql.org>
MIME-Version: 1.0
To: Adam Manock <abmanock@planetcable.net>
CC: pgsql-general@postgresql.org
Subject: Re: Performance tuning for linux, 1GB RAM, dual CPU?
References: <5146853DD571D411AC54000102070D611C7F10@MINGBGNTS02>
	<5146853DD571D411AC54000102070D611C7F10@MINGBGNTS02>
	<5.1.0.14.2.20010711151558.00ac0590@pop.planetcable.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Adam,

There are a few links to benchmark-type things you might find useful at
:

http://techdocs.postgresql.org/oresources.php#benchmark

Hope they're useful.

:-)

Regards and best wishes,

Justin Clift

Adam Manock wrote:
> 
>  >This is almost certainly a lousy idea.  You do *not* want to chew up all
>  >available memory for PG shared buffers; you should leave a good deal of
>  >space for kernel-level disk buffers.
> 
> I decided to start high on buffers because of Bruce's:
>         http://www.ca.postgresql.org/docs/hw_performance/
>  From that I get the impression that operations using kernel disk buffer
> cache are considerably more expensive than if the data was in shared
> buffer cache, and that increasing PG's memory usage until the system
> is almost using swap is The Right Thing To Do.  Has anyone got real
> world test data to confirm or refute this??
>     If not, then I am going to need to find or create a benchmarking program
> to load down PG against a fake multi-gigabyte "production" database.
> Or I could wait a week to see what RedHat does to tune their
> implementation of PG :-)
> 
> Adam
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org