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?
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.
In response to
pgsql-performance by date
|Next:||From: Aidan Van Dyk||Date: 2009-09-25 16:15:42|
|Subject: Re: PG 8.3 and large shared buffer settings|
|Previous:||From: Craig James||Date: 2009-09-25 15:22:16|
|Subject: Re: High CPU load on Postgres Server during Peak times!!!!|