Is there any practical limit to the number of shared buffers PG 8.3.7
can handle before more becomes counter-productive? I remember the
buffer management algorithm used to get unhappy with too many buffers
and past a certain point performance dropped with extra memory
pitched at Postgres.

My production DB's around 200G, and the box hosting it has 192G of
memory on it, running a 64 bit AIX build of 8.3.7. I'm currently
running with 15G of shared buffers, and while performance is pretty
good, things still hit the disk more than I'd like. I can easily bump
the shared buffer setting up to 40G or so without affecting anything
else that matters.

The box runs other things as well as the database, so the OS buffer
cache tends to get effectively flushed -- permanently pinning more of
the database in memory would be an overall win for DB performance,
assuming bad things don't happen because of buffer management.
(Unfortunately I've only got a limited window to bounce the server,
so I can't do too much in the way of experimentation with buffer

--------------------------------------it's like this-------------------
Dan Sugalski even samurai have teddy bears and even
teddy bears get drunk

Search Discussions

Discussion Posts

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 16 | next ›
Discussion Overview
grouppgsql-performance @
postedSep 25, '09 at 3:28a
activeSep 28, '09 at 6:00p



site design / logo © 2019 Grokbase