Shaun Thomas wrote: > On 10/30/2012 06:55 AM, Kevin Grittner wrote: >> Is there a good transaction-based connection pooler in Python? >> You're better off with a good pool built in to the client >> application than with a good pool running as a separate process >> between the client and the database, IMO. > > Could you explain this a little more? My experience is almost > always the exact opposite, especially in large clusters that may > have dozens of servers all hitting the same database. A > centralized pool has much less duplication and can serve from a > smaller pool than having 12 servers each have 25 connections > reserved in their own private pool or something. > > I mean... a pool is basically a proxy server. I don't have 12 > individual proxy servers for 12 webservers. Sure, if you have multiple web servers and they are not routing their database requests through a common "model" layer, an external pooler would make sense. Most of the time I've dealt either with one web server or multiple servers routing requests at the transaction level to a single JVM which ran the logic of the transaction -- either of which is a good place to have a connection pool. A dozen different JVMs all making JDBC requests does kind of beg for an external layer to concentrate the requests; if it isn't something that's running the transaction layer, a connection pooler there would be good. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
