From: Josh Berkus <josh@agliodbs.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Craig Ringer <craig@postnewspapers.com.au>
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:42:11 -0700
Message-ID: <4C38BF03.6060503@agliodbs.com> (raw)
In-Reply-To: <AANLkTimNJZlX7kFH_r0-BB_K3NGorU7BHd85SxXJbuGJ@mail.gmail.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>
<4C37EA1D.6000008@postnewspapers.com.au>
<AANLkTimNJZlX7kFH_r0-BB_K3NGorU7BHd85SxXJbuGJ@mail.gmail.com>
> Right, let's not confuse Kevin's argument that we should have
> connection pooling in core with advocacy for any particular patch or
> feature suggestion that he may have offered on some other thread. A
> very simple in-core connection pooler might look something like this:
> when a session terminates, the backend doesn't exit. Instead, it
> waits for the postmaster to reassign it to a new connection, which the
> postmaster does in preference to starting new backends when possible.
> But if a backend doesn't get assigned a new connection within a
> certain period of time, then it goes ahead and exits anyway.
This would, in my opinion, be an excellent option for PostgreSQL and
would save a LOT of newbie pain. Going back to my list, it would help
with both problems (a) and (c). It wouldn't be as good as pgbouncer,
but it would be "good enough" for a lot of users.
HOWEVER, there is the issue that such a mechanism isn't "free". There
are issue with sharing backends around GUCs, user configuration,
security, and prepared plans -- all issues which presently cause people
difficulty with pgbouncer. I think the costs are worth it, but we'd
have to make some attempt to tackle those issues as well. And, of
course, we'd need to let DBAs turn the pooling off.
I'd envision parameters:
pool_connections true/false
pool_connection_timeout 60s
> I'm also relying on the unsubstantiated assumption that it's
> possible to pass a socket connection between processes.
Doesn't pgpool do this?
> Still another approach is admission control based on transactions,
> backends, queries, memory usage, I/O, or what have you.
That's a different problem, and on its own doesn't help newbies. It's
complimetary to pooling, though, so would be nice to have.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
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: josh@agliodbs.com, robertmhaas@gmail.com, craig@postnewspapers.com.au, 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: <4C38BF03.6060503@agliodbs.com>
* 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