From: Craig Ringer <craig@postnewspapers.com.au>
To: Josh Berkus <josh@agliodbs.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Greg Smith <greg@2ndquadrant.com>
Cc: Matthew Wakeling <matthew@flymine.org>
Cc: Brad Nicholson <bnichols@ca.afilias.info>
Cc: pgsql-performance@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
Date: Sat, 10 Jul 2010 11:33:49 +0800
Message-ID: <4C37EA1D.6000008@postnewspapers.com.au> (raw)
In-Reply-To: <4C37CBFB.1000800@agliodbs.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>
<4C37791C0200002500033379@gw.wicourts.gov>
<4C37CBFB.1000800@agliodbs.com>
On 10/07/2010 9:25 AM, Josh Berkus wrote:
>
>> It *is* the last place you want to put it, but putting it there can
>> be much better than not putting it *anywhere*, which is what we've
>> often seen.
>
> Well, what you proposed is an admission control mechanism, which is
> *different* from a connection pool, although the two overlap. A
> connection pool solves 4 problems when it's working:
>
> a) limiting the number of database server processes
> b) limiting the number of active concurrent queries
> c) reducing response times for allocating a new connection
> d) allowing management of connection routes to the database
> (redirection, failover, etc.)
I agree with you: for most Pg users (a) is really, really important. As
you know, in PostgreSQL each connection maintains not only general
connection state (GUC settings, etc) and if in a transaction,
transaction state, but also a query executor (full backend). That gets
nasty not only in memory use, but in impact on active query performance,
as all those query executors have to participate in global signalling
for lock management etc.
So an in-server pool that solved (b) but not (a) would IMO not be
particularly useful for the majority of users.
That said, I don't think it follows that (a) cannot be solved in-core.
How much architectural change would be required to do it efficiently
enough, though...
--
Craig Ringer
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: craig@postnewspapers.com.au, josh@agliodbs.com, Kevin.Grittner@wicourts.gov, greg@2ndquadrant.com, matthew@flymine.org, bnichols@ca.afilias.info, tgl@sss.pgh.pa.us
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
In-Reply-To: <4C37EA1D.6000008@postnewspapers.com.au>
* 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