The never ending quest for clarity on shared_buffers - Mailing list pgsql-performance

From Doug Y
Subject The never ending quest for clarity on shared_buffers
Date
Msg-id 6.1.2.0.2.20041006152747.033bcd50@pop.traderonline.com
Whole thread Raw
Responses Re: The never ending quest for clarity on shared_buffers
List pgsql-performance
Hello,
   We recently upgraded os from rh 7.2 (2.4 kernel) to Suse 9.1 (2.6
kernel), and psql from 7.3.4 to 7.4.2

   One of the quirks I've noticed is how the queries don't always have the
same explain plans on the new psql... but that's a different email I think.

   My main question is I'm trying to convince the powers that be to let me
use persistent DB connections (from apache 2 / php), and my research has
yielded conflicting documentation about the shared_buffers setting... real
shocker there :)

   For idle persistent connections, do each of them allocate the memory
specified by this setting (shared_buffers * 8k), or is it one pool used by
all the connection (which seems the logical conclusion based on the name
SHARED_buffers)? Personally I'm more inclined to think the latter choice,
but I've seen references that alluded to both cases, but never a definitive
answer.

   For what its worth, shared_buffers is currently set to 50000 (on a 4G
system). Also, effective_cache_size is 125000. max_connections is 256, so I
don't want to end up with a possible 100G (50k * 8k * 256) of memory tied
up... not that it would be possible, but you never know.

   I typically never see more than a dozen or so concurrent connections to
the db (serving 3 web servers), so I'm thinking of actually using something
like pgpool to keep about 10 per web server, rather than use traditional
persistent connections of 1 per Apache child, which would probably average
about 50 per web server.

Thanks.


pgsql-performance by date:

Previous
From: Greg Stark
Date:
Subject: Re: sequential scan on select distinct
Next
From: Tom Lane
Date:
Subject: Re: sequential scan on select distinct