On Wed, 2010-07-14 at 08:58 -0500, Kevin Grittner wrote: > Scott Marlowe <scott.marl...@gmail.com> wrote: > > Hannu Krosing <ha...@2ndquadrant.com> wrote: > >> One example where you need a separate connection pool is pooling > >> really large number of connections, which you may want to do on > >> another host than the database itself is running. > > > > Definitely. Often it's best placed on the individual webservers > > that are making requests, each running its own pool. > > Each running its own pool? You've just made a case for an > admissions policy based on active database transactions or active > queries (or both) on the server having a benefit when used with this > pooling arrangement. This collection of pools can't know when the > CPUs have enough to keep them busy and adding more will degrade > performance.
I guess this setup is for OLTP load (read "lots of short transactions with low timeout limits"), where you can just open 2-5 connections per CPU for mostly-in-memory database, maybe a little more when disk accesses are involved. If you have more, then they just wait a few milliseconds, if you have less, you don't have anything else to run anyway. -- Hannu Krosing http://www.2ndQuadrant.com PostgreSQL Scalability and Availability Services, Consulting and Training -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
