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
