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 uses a ring buffer for each scan). So, for any data that is only accessed by sequential scan, you're relying on the OS and the 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(at)postgresql(dot)org [pgsql-performance-owner(at)postgresql(dot)org] On Behalf Of Aidan Van Dyk [aidan(at)highrise(dot)ca]
Sent: Friday, September 25, 2009 6:33 AM
To: Dan Sugalski
Cc: Tom Lane; pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] PG 8.3 and large shared buffer settings

* Dan Sugalski <dan(at)sidhe(dot)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(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.