From: Josh Berkus <josh@agliodbs.com>
Organization: Aglio Database Solutions
To: pgsql-performance@postgresql.org
Subject: Re: Postgresql on an AMD64 machine
Date: Tue, 7 Jun 2005 20:05:47 -0700
User-Agent: KMail/1.8
References: <1118080420.1644.23.camel@penguin1>
	<20050607202755.GA28361@surnet.cl> <18285.1118178689@sss.pgh.pa.us>
In-Reply-To: <18285.1118178689@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200506072005.47418.josh@agliodbs.com>

Tom,

> Obviously we'd be willing to do this work if there were convincing
> evidence it'd be worth the time.  A benchmark showing performance
> continuing to climb with increasing shared_buffers right up to the 2Gb
> limit would be reasonably convincing.  I think there is 0 chance of
> drawing such a graph with a pre-8.1 server, because of internal
> inefficiencies in the buffer manager ... but with CVS tip the story
> might be different.

Not that I've seen in testing so far.   Your improvements have, fortunately, 
eliminated the penalty for allocating too much shared buffers as far as I can 
tell (at least, allocating 70,000 when gains stopped at 15,000 doesn't seem 
to carry a penalty), but I don't see any progressive gain with increased 
buffers above the initial ideal.  In fact, with clock-sweep the shared_buffer 
curve is refreshingly flat once it reaches the required level, which will 
take a lot of the guesswork out of allocating buffers.

Regarding 2GB memory allocation, though, we *could* really use support for 
work_mem and maintenance_mem of > 2GB.   

-- 
Josh Berkus
Aglio Database Solutions
San Francisco