On Fri, 29 May 2009, Grzegorz Ja?kiewicz wrote:
> if it is implemented somewhere else better, shouldn't that make it
> obvious that postgresql should solve it internally ?
Opening a database connection has some overhead to it that can't go away
without losing *something* in the process that you want the database to
handle. That something usually impacts either security or crash-safety.
This is why every serious database product in the world suggests using
connection pooling; examples:
http://blogs.oracle.com/opal/2006/10/oracle_announces_new_connectio.html
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/conn/c0006170.htm
http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx
http://dev.mysql.com/tech-resources/articles/connection_pooling_with_connectorj.html
The only difference here is that some of the commercial products bundle
the connection pooler into the main program. In most cases, you're still
stuck with configuring a second piece of software, the only difference is
that said software might already be installed for you by the big DB
installer. Since this project isn't in the business of bundling every
piece of additional software that might be useful with the database, it's
never going to make it into the core code when it works quite happily
outside of it. The best you could hope for is that people who bundle
large chunks of other stuff along with their PostgreSQL installer, like
Enterprise DB does, might include one of the popular poolers one day.
And that's how we got to here. There are plenty of PostgreSQL problems
one might run into that there are no usable solutions to, but that other
database vendors have already solved nicely. From a pragmatic standpoint,
I'd rather see people work on those, rather than try and forge new ground
on a problem everyone else in the industry has failed to solve.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD