From: Josh Berkus <josh@agliodbs.com>
Organization: PostgreSQL @ Sun
To: pgsql-performance@postgresql.org
Subject: Re: Tuning
Date: Sun, 28 Jan 2007 15:24:24 -0800
User-Agent: KMail/1.8.2
Cc: "John Parnefjord" <John.Parnefjord@kib.ki.se>
References: <76C73999206F3145A2E3046A5C32A103F02A5A@kibmail.kib.local>
In-Reply-To: <76C73999206F3145A2E3046A5C32A103F02A5A@kibmail.kib.local>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200701281524.24317.josh@agliodbs.com>

John,

> -work_mem

Depends on the number of concurrent queries you expect to run and what size 
sorts you expect them to do.

> -maintenance_work_mem - 50% of the largest table?

Actually, in current code I've found that anything over 256mb doesn't actually 
get used.

> -shared_buffers - max value 50000

Actually, I need to update that.   On newer faster multi-core machines you may 
want to allocate up to 1GB of shared buffers.

> -effective_cache_size - max 2/3 of available ram, ie 24GB on the
> hardware described above

Yes.

> -shmmax - how large dare I set this value on dedicated postgres servers?

Set it to 2GB and you'll be covered.

> -checkpoint_segments - this is crucial as one of the server is
> transaction heavy

Well, it only helps you to raise this if you have a dedicated disk resource 
for the xlog.   Otherwise having more segments doesn't help you much.

> -vacuum_cost_delay

Try 200ms to start.

Also, set wal_buffers to 128.

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco