Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 6E7AA63288E for ; Sat, 10 Jul 2010 03:33:48 -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 14705-01 for ; Sat, 10 Jul 2010 06:33:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from shrek.krogh.cc (2605ds1-ynoe.0.fullrate.dk [90.184.12.24]) by mail.postgresql.org (Postfix) with ESMTP id D65C5632769 for ; Sat, 10 Jul 2010 03:33:40 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by shrek.krogh.cc (Postfix) with ESMTP id E325A1F0E4F; Sat, 10 Jul 2010 08:33:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at shrek.krogh.cc Received: from shrek.krogh.cc ([127.0.0.1]) by localhost (shrek.krogh.cc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlOuEr6WHsMf; Sat, 10 Jul 2010 08:33:34 +0200 (CEST) Received: from [90.184.13.151] (2605ds1-ynoe.2.fullrate.dk [90.184.13.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jesper@krogh.cc) by shrek.krogh.cc (Postfix) with ESMTPSA id 7C1131F0E1E; Sat, 10 Jul 2010 08:33:34 +0200 (CEST) Message-ID: <4C38143C.3080304@krogh.cc> Date: Sat, 10 Jul 2010 08:33:32 +0200 From: Jesper Krogh User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100528 Thunderbird/3.0.5 MIME-Version: 1.0 To: Greg Smith CC: Matthew Wakeling , Kevin Grittner , Brad Nicholson , pgsql-performance@postgresql.org, Tom Lane Subject: Re: Need help in performance tuning. References: <4C369346.6010501@postnewspapers.com.au> <8760.1278650566@sss.pgh.pa.us> <1278680186.1914.36.camel@bnicholson-desktop> <4C36F57102000025000332F6@gw.wicourts.gov> <4C36FEAD02000025000332FC@gw.wicourts.gov> <4C37A9C1.1060405@2ndquadrant.com> In-Reply-To: <4C37A9C1.1060405@2ndquadrant.com> Content-Type: multipart/alternative; boundary="------------090601050108050002090101" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.899 tagged_above=-10 required=5 tests=BAYES_00=-1.9, HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 201007/173 X-Sequence-Number: 39562 This is a multi-part message in MIME format. --------------090601050108050002090101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2010-07-10 00:59, Greg Smith wrote: > Matthew Wakeling wrote: > > If you have an external pool solution, you can put it somewhere > > else - maybe on multiple somewhere elses. > > This is the key point to observe: if you're at the point where you > have so many connections that you need a pool, the last place you > want to put that is on the overloaded database server itself. > Therefore, it must be an external piece of software to be effective, > rather than being part of the server itself. Database servers are > relatively expensive computing hardware due to size/quantity/quality > of disks required. You can throw a pooler (or poolers) on any cheap > 1U server. This is why a built-in pooler, while interesting, is not > particularly functional for how people normally scale up real-world > deployments. That may be totally correct for the 10% of the userbase that are in a squeezed situation, but for the 90% that isn't (or isn't aware of being there), the build-in would be a direct benefit. For the 20% living near the "edge" it may be the difference between "just working" and extra hassle. I think it is a fair assumption that the majority of PG's users solves the problems without an connection pooler, and the question is if it is beneficial to let them scale better without doing anything? I have also provided a case where Kevin proposal "might" be a benefit but a connection pooler cannot solve it: http://archives.postgresql.org/pgsql-hackers/2010-06/msg01438.php (at least as I see it, but I'm fully aware that there is stuff I dont know of) I dont think a build-in connection-poller (or similiar) would in any way limit the actions and abillities of an external one? * Both numbers wildly guessed.. -- Jesper --------------090601050108050002090101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2010-07-10 00:59, Greg Smith wrote:
> Matthew Wakeling wrote:
>> If you have an external pool solution, you can put it somewhere
>> else - maybe on multiple somewhere elses.
>
> This is the key point to observe:  if you're at the point where you
> have so many connections that you need a pool, the last place you
> want to put that is on the overloaded database server itself.
> Therefore, it must be an external piece of software to be effective,
> rather than being part of the server itself.  Database servers are
> relatively expensive computing hardware due to size/quantity/quality
> of disks required.  You can throw a pooler (or poolers) on any cheap
> 1U server.  This is why a built-in pooler, while interesting, is not
> particularly functional for how people normally scale up real-world
> deployments.

That may be totally correct for the 10% of the userbase
that are in a squeezed situation, but for the 90% that isn't (or isn't aware
of being there), the build-in would be a direct benefit. For the 20%
living near the "edge" it may be the difference between "just working" and
extra hassle.

I think it is a fair assumption that the majority of PG's users solves
the problems without an connection pooler, and the question
is if it is beneficial to let them scale better without doing anything?

I have also provided a case where Kevin proposal "might" be a
benefit but a connection pooler cannot solve it:
 
http://archives.postgresql.org/pgsql-hackers/2010-06/msg01438.php
(at least as I see it, but I'm fully aware that there is stuff I dont know of)

I dont think a build-in connection-poller (or similiar) would in any
way limit the actions and abillities of an external one?

* Both numbers wildly guessed..
--
Jesper



--------------090601050108050002090101--