Connection Pooling in PostgreSQL

Hi PostgreSQL Guru's

Is connection pooling available in PostgreSQL ? If yes, please give links to resources.

Do give your valuable input.

Best Regards.

ggnanaraj,

I think Bob is onto something. As far as I know, Postgres DOES NOT handle any connection pooling. That doesn't mean you can't use it. Just means you need something else that does support it, like an application/middle tier server.

So in your case I am assuming that this is handled by the JBoss server you are using. While I'm not familiar with JBoss, I would start there. They tout themselves as having the best java application server out there, so I'm guessing this is a feature that has been around for a long time. If it's in Tomcat as Bob pointed out, surely it's in JBoss.

JBoss pools JDBC connections using something called Minerva, I'm not sure what this is but that's what I keep reading about.

Thanks for the valuable input. Appreciate it.

Best Regards.

Connection pooling is not a database function but an application environment function. For example, as seen above, any JDBC-enabled database system can have connections pooled by Java.

PHP at present does not have native connection pooling, but there is a third-party project which provides that: www.vl-srm.net. This is essentially a PHP "back end", which keeps variables, objects, connections alive for access from any PHP script.

There is also another open source project called SQL Relay which is a "generic" database connection pooler, which can serve data to many programming environments, including PHP, Perl, and Java.

rycamor,

Do you consider the persistent connections in PHP (pg_pconnect versus pg_connect) to be connection pooling? I use the persistent connections and was always thought this to be a type of connection pooling.

Persistent isn't the same thing as shared. With persistent connections, that just means that when a particular script's execution ends, the connection is left open by that httpd process so that it will be available for the next script which this process will serve. So, it is still one connection per script, we just avoid the startup/shutdown costs, to a certain extent.

This is different from connection pooling, where an intermediary process maintains a set of open connections for sharing. For example this pooling agent might pass several SQL queries through one connection, from different request objects, and return the results, each to it's respective owner. This means the pooling agent can properly schedule the available number of open connections, using each one as efficiently as possible.

In the PHP isn't an Enterprise Solution thread, we discussed this, in the last few posts. (rod k had some good perspective on this). One thing to remember is that this does involve the in-memory cost of an open httpd process, so there can be drawbacks, especially if you are also serving a lot of static content from the same httpd daemon. (There might be many useless connections held open for no good reason)

Thanks for the clarification rycamor, that makes alot of sense.

It has started to click now why an app like SRM would make sense.

I know that I use alot of session variables that are passed between pages, and let me tell you, it's a royal pain in the ***. I can't imagine how much degradation all those disk writes are causing either.

Being able to cache sessions in memory would ROCK.