From: Jesper Krogh <jesper@krogh.cc>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Matthew Wakeling <matthew@flymine.org>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Brad Nicholson <bnichols@ca.afilias.info>
Cc: pgsql-performance@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Need help in performance tuning.
Date: Sat, 10 Jul 2010 08:33:32 +0200
Message-ID: <4C38143C.3080304@krogh.cc> (raw)
In-Reply-To: <4C37A9C1.1060405@2ndquadrant.com>
References: <AANLkTiknhZhKtGDidBsMWtPJpRgln9DrrsCebCEYk5XE@mail.gmail.com>
<4C369346.6010501@postnewspapers.com.au>
<AANLkTin4Q4APRnbJ85FRasU7n8LuhKibKYcGnexsEbTt@mail.gmail.com>
<8760.1278650566@sss.pgh.pa.us>
<1278680186.1914.36.camel@bnicholson-desktop>
<4C36F57102000025000332F6@gw.wicourts.gov>
<alpine.DEB.2.00.1007091621380.2534@aragorn.flymine.org>
<4C36FEAD02000025000332FC@gw.wicourts.gov>
<alpine.DEB.2.00.1007091753350.2534@aragorn.flymine.org>
<4C37A9C1.1060405@2ndquadrant.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: jesper@krogh.cc, greg@2ndquadrant.com, matthew@flymine.org, Kevin.Grittner@wicourts.gov, bnichols@ca.afilias.info, tgl@sss.pgh.pa.us
Subject: Re: Need help in performance tuning.
In-Reply-To: <4C38143C.3080304@krogh.cc>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox