Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id C253F632975 for ; Wed, 14 Jul 2010 11:55:02 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 47076-04 for ; Wed, 14 Jul 2010 14:54:53 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from serenity.inversion.ee (serenity.inversion.ee [194.204.33.112]) by mail.postgresql.org (Postfix) with ESMTP id 8262363291E for ; Wed, 14 Jul 2010 11:54:55 -0300 (ADT) Received: by serenity.inversion.ee (Postfix, from userid 108) id 1EF6AE34436; Wed, 14 Jul 2010 16:36:55 +0300 (EEST) Received: from [IPv6:::1] (localhost [127.0.0.1]) by serenity.inversion.ee (Postfix) with ESMTP id 7BBC3E34252; Wed, 14 Jul 2010 16:36:54 +0300 (EEST) Subject: Re: Need help in performance tuning. From: Hannu Krosing To: Kevin Grittner Cc: Scott Marlowe , Samuel Gendler , pgsql-performance@postgresql.org, Tom Lane In-Reply-To: <4C3D7C2F020000250003353C@gw.wicourts.gov> References: <4C369346.6010501@postnewspapers.com.au> <8760.1278650566@sss.pgh.pa.us> <1278654529.7216.20.camel@hvost> <4C3D7C2F020000250003353C@gw.wicourts.gov> Content-Type: text/plain; charset="UTF-8" Date: Wed, 14 Jul 2010 17:54:51 +0300 Message-ID: <1279119291.3888.5.camel@hvost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201007/227 X-Sequence-Number: 39616 On Wed, 2010-07-14 at 08:58 -0500, Kevin Grittner wrote: > Scott Marlowe wrote: > > Hannu Krosing 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