DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
	b=RkuZVa9LRzE41nBJrPuTmzjXMfcohmJAm7mV8HADkI9fOYHBfn36AWSUWv7W6ApcqYav6CzsyCMSI8f4ZCG/pKojCJXWYJ6EVViQdD+Ewg6xdktkv3nAwm+HZRzcIkPQaFOLs0h2V0tBCxf2qWRqOEYyUezFG/OVWU5nTBuv8A8=
Message-ID: <4645CF1D.1030309@enterprisedb.com>
Date: Sat, 12 May 2007 15:28:45 +0100
From: Heikki Linnakangas <heikki@enterprisedb.com>
User-Agent: Icedove 1.5.0.10 (X11/20070329)
MIME-Version: 1.0
To: Michael van Rooyen <mvanr@bigfoot.com>
CC: pgsql-performance@postgresql.org
Subject: Re: Kernel cache vs shared_buffers
References: <00b301c79486$1c54da80$0200a8c0@saturn>
In-Reply-To: <00b301c79486$1c54da80$0200a8c0@saturn>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Michael van Rooyen wrote:
> I have no idea regarding the inner working of the pg's shared cache, but 
> what I would like to find out is whether it is table-row-based, or 
> disk-block-based.  

It's block based.

> In the case of it being disk-block based, my 
> inclination would be to let the kernel do the buffering.  In the case of 
> the cache being table-row-based, I would expect it to be much more 
> space-efficient and I would be inclined to give the memory to the pg.  
> In that case, is it feasible to set shared_buffers to something like 
> 500000 x 8k blocks?  We make extensive use of indexes on the larger 
> tables and would seldom, if ever, do sequential scans.

A common rule of thumb people quote here is to set shared_buffers to 1/4 
of available RAM, and leave the rest for OS cache. That's probably a 
good configuration to start with.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com