Message-ID: <48033F39.1060004@archonet.com>
Date: Mon, 14 Apr 2008 12:25:45 +0100
From: Richard Huxton <dev@archonet.com>
User-Agent: Thunderbird 2.0.0.12 (X11/20080213)
MIME-Version: 1.0
To: Gregory Stark <stark@enterprisedb.com>
CC: Gaetano Mendola <mendola@gmail.com>,
 pgsql-performance@postgresql.org
Subject: Re: shared_buffers performance
References: <48032021.90704@gmail.com> <87r6d8hfgw.fsf@oxford.xeocode.com>
In-Reply-To: <87r6d8hfgw.fsf@oxford.xeocode.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gregory Stark wrote:
> "Gaetano Mendola" <mendola@gmail.com> writes:
> 
>> The following graph reports the results:
>>
>> http://img84.imageshack.us/my.php?image=totalid7.png
> 
> That's a *fascinating* graph.

It is, isn't it? Thanks Gaetano.

> It seems there are basically three domains. 
> 
> The small domain where the database fits in shared buffers -- though actually
> this domain seems to hold until the accounts table is about 1G so maybe it's
> more that the *indexes* fit in memory. Here larger shared buffers do clearly
> win.

I think this is actually in two parts - you can see it clearly on the 
red trace (64MB), less so on the green (256MB) and not at all on the 
blue (512MB). Presumably the left-hand steeper straight-line decline 
starts with the working-set in shared-buffers, and the "knee" is where 
we're down to just indexes in shared-buffers.

With the blue I guess you just get the first part, because by the time 
you're overflowing shared-buffers, you've not got enough disk-cache to 
take up the slack for you.

I wonder what difference 8.3 makes to this?

-- 
   Richard Huxton
   Archonet Ltd