Message-ID: <4C3AF564.5030204@postnewspapers.com.au>
Date: Mon, 12 Jul 2010 18:58:44 +0800
From: Craig Ringer <craig@postnewspapers.com.au>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: Matthew Wakeling <matthew@flymine.org>
CC: pgsql-performance@postgresql.org
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
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>
	<4C38BF03.6060503@agliodbs.com> <19244.1278787866@sss.pgh.pa.us>
	<alpine.DEB.2.00.1007121044330.2534@aragorn.flymine.org>
In-Reply-To: <alpine.DEB.2.00.1007121044330.2534@aragorn.flymine.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 12/07/10 17:45, Matthew Wakeling wrote:
> 
> I'm surprised. Doesn't apache httpd do this? Does it have to do a whole
> load of non-portable stuff? It seems to work on a whole load of platforms.

A lot of what Apache HTTPd does is handled via the Apache Portable
Runtime (APR). It contains a lot of per-platform handlers for various
functionality.

http://apr.apache.org/docs/apr/1.4/modules.html

I don't know if the socket passing is provided as part of APR or is part
of Apache HTTPd its self, but I wouldn't be at all surprised if it was
in APR.

Personally I'm now swayed by arguments presented here that trying to
push pooling into core isn't really desirable, and that better
packaging/bundling of existing solutions would be better.

Perhaps documenting the pluses/minuses of the current pooling options
and providing clear recommendations on which to use for different use
cases would help, since half the trouble is users not knowing they need
a pool or being confused as to which to select.

This discussion reminds me a bit of Hibernate's built-in client-side
connection pool. It has one, but it's a unloved stepchild that even the
Hibernate devs suggest should be avoided in favour of a couple of
external 3rd party options.

A built-in pool seems like a great idea, but there are multiple existing
ones because they solve different problems in different ways. Unless a
built-in one could solve ALL those needs, or be so vastly simpler (due
to code re-use, easier configuration, etc) that it's worth building one
that won't fit everyone's needs, then it's best to stick to the existing
external options.

So rather than asking "should core have a connection pool" perhaps
what's needed is to ask "what can an in-core pool do that an external
pool cannot do?"

Admission control / resource limit features would be great to have in
core, and can't really be done fully in external modules ... but could
be designed in ways that would allow external poolers to add
functionality on top. Josh Berkus has made some good points on why this
isn't as easy as it looks, though:


http://it.toolbox.com/blogs/database-soup/admission-control-and-its-discontents-39895

--
Craig Ringer