On Tue, Oct 4, 2011 at 9:11 AM, Alexander Farber <alexander.farber@xxxxxxxxx> wrote: > Hello, > > I run a LAPP server (PostgreSQL 8.4 @ CentOS 5.7 / 64 bit; > only 4 GB RAM) with the following config: > > postgresql.conf (unix socket only and - ): > > max_connections = 50 > shared_buffers = 1024MB # min 128kB OK, so a lot of folks think the only way to take advantage of the extra memory is for postgresql to directly manage and use it. this is a rather naive view. PostgreSQL can use some of it for sorts etc, index rebuilds and so on, in addition to using it for shared buffers. Further the kernel uses what's not being used elsewhere for file system caching, so often there's no real gain from having postgresql try to cache more data when the OS is already doing it, and for large amounts of memory, usually doing it better. On top of that, the dirty buffers have to get written out to disk eventually, and on a transactional system having more dirty buffers to manage just makes things slower not faster. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
