Re: too many clients

Per your direction, pg_pConnect is great when you have one site
dedicated on one box talking to another dedicated PgSQL box. It does
not make sense in mass vhosting environments. Using pg_pConnect greatly
reduces execution time in an environment where you're not fighting for
resources. I use it on a few very high traffic sites without issue, but
it is tuned so that there is only 1 persistant connection per apache
backend and postgresql will allow the max apache backends, which by
default is generally 256. I highly recommend it in such a situation,
while I generally do not recommend it in any other.

Gavin

On Wed, 2004-12-29 at 13:13 -0500, Frank Bax wrote:
> At 12:12 PM 12/29/04, Matthew Terenzio wrote:
>
>
> >On Dec 29, 2004, at 11:38 AM, Mitch Pirtle wrote:
> >
> >>You got a couple solutions, one of which is getting a connection
> >>pooler setup between apache(php) and postgres. SQL Relay
> >>(sqlrelay.sf.net) could be a common candidate, as I have used it in
> >>the past with great results.
> >
> >Yes, I have taken a look at that before. It might be a good time to try it.
> >
> >I don't exactly understand the technical difference between pooled
> >connections and persistent ones.
> >
> >pg_pconnect() is grabbing an existing open connection if one is available.
> >
> >How is a connection pool more efficient in doing something along these lines?
>
>
> Have you read the php docs on persistent connections?
> http://www.php.net/manual/en/features.persistent-connections.php
> pg_pconnect is sometimes used in situations where it does not make sense.
>
> As you mentioned, apache uses numerous child process. A persistent
> connection can only be reused if the following things are the same:
> - same apache child process requests the connection
> - same connect string (ie host, database, user are *all* the same)
>
> If you have a site where there are many databases and/or many users, it is
> very easy for apache to retain more persistent connections than your
> postgres limit. There are many variables when trying to figure out which
> function works better, so simply try it on your own system. If pg_connect
> does not add significant overhead, and manages to avoid the problems you
> mentioned, then use it instead of pg_pconnect.
>
> I haven't heard of pooled connections, but can only assume they somehow
> overcome the problems with pg_pconnect gets out of control - perhaps the
> connections are shared across apache child processes.
>
> Frank
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org