Re: Kernel cache vs shared_buffers - Mailing list pgsql-performance

From Heikki Linnakangas
Subject Re: Kernel cache vs shared_buffers
Date
Msg-id 4645CF1D.1030309@enterprisedb.com
Whole thread Raw
In response to Kernel cache vs shared_buffers  ("Michael van Rooyen" <mvanr@bigfoot.com>)
Responses Re: Kernel cache vs shared_buffers
Re: Kernel cache vs shared_buffers
List pgsql-performance
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

pgsql-performance by date:

Previous
From: "Michael van Rooyen"
Date:
Subject: Kernel cache vs shared_buffers
Next
From: "Jim C. Nasby"
Date:
Subject: Re: estimating the need for VACUUM FULL and REINDEX