Matthew Wakeling <matthew@xxxxxxxxxxx> wrote: > On Fri, 9 Jul 2010, Kevin Grittner wrote: >>> Interesting idea. As far as I can see, you are suggesting >>> solving the too many connections problem by allowing lots of >>> connections, but only allowing a certain number to do anything >>> at a time? >> >> Right. > > I think in some situations, this arrangement would be an > advantage. However, I do not think it will suit the majority of > situations, and could reduce the performance when the user doesn't > need the functionality, either because they have a pool already, > or they don't have many connections. Oh, totally agreed, except that I think we can have essentially nil impact if they don't exceed a configured limit. In my experience, pooling is more effective the closer you put it to the client. I suppose the strongest argument that could be made against building in some sort of pooling is that it doesn't encourage people to look for client-side solutions. However, we seem to get a lot of posts from people who don't do this, are not able to easily manage it, and who would benefit from even a simple solution like this. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
