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-ow...@postgresql.org [pgsql-performance-ow...@postgresql.org] On Behalf Of Aidan Van Dyk [ai...@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 <d...@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, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
