Re: PG 8.3 and large shared buffer settings

That won't work well anyway because the postgres shared_buffers dos not cache things that are sequentially scanned (it
usesa ring buffer for each scan).  So, for any data that is only accessed by sequential scan, you're relying on the OS
andthe disks.  If you access a table via index scan though, all its pages will go through shared_buffers. 

Size shared_buffers to no more than the 'hot' space of index and randomly accessed data.

________________________________________
From: pgsql-performance-owner@postgresql.org [pgsql-performance-owner@postgresql.org] On Behalf Of Aidan Van Dyk
[aidan@highrise.ca]
Sent: Friday, September 25, 2009 6:33 AM
To: Dan Sugalski
Cc: Tom Lane; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] PG 8.3 and large shared buffer settings

* Dan Sugalski <dan@sidhe.org> [090925 06:06]:

> I'll have to go check, but I think it does. This box hasn't actually hit
> swap since it started --  a good chunk of that RAM is used as
> semi-permanent disk cache but unfortunately the regular day-to-day use of
> this box (they won't let me have it as a dedicated DB-only machine. Go
> figure :) doing other stuff the cache tends to turn over pretty quickly.

All the more reason to find a way to use it all as shared buffers and
lock it into ram...

Oh, sorry, you expect the DB to play nice with everything else?

;-)

a.

--
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.