On Tue, 2010-09-14 at 10:10 -0600, mark wrote: > Hello, > > I am relatively new to postgres (just a few months) so apologies if > any of you are bearing with me. > > I am trying to get a rough idea of the amount of bang for the buck I > might see if I put in a connection pooling service into the enviroment > vs our current methodology of using persistent open connections. Well what a pooler does is provide persisten open connections that can be reused. What tech are you using for these persisten open connections? > Most of the connections from the various apps hold idle connections > until they need to execute a query once done go back to holding an > open idle connection. (there are ~600 open connections at any given > time, and most of the time most are idle) Sounds like each app is holding its own pool? > I think from reading this list for a few weeks the answer is move to > using connection pooling package elsewhere to better manage incoming > connections, with a lower number to the db. Correct, because each connection is overhead. If you have 600 connections, of which really only 20 are currently executing, that is highly inefficient. A pooler would have say, 40 connections open, with 20 currently executing and a max pool of 600. > > I am told this will require some re-working of some app code as I > understand pg-pool was tried a while back in our QA environment and > server parts of various in-house apps/scripts/..etc started to > experience show stopping problems. Use pgbouncer. It is what Skype uses. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
