Received: from maia.hub.org (maia-2.hub.org [200.46.204.251])
	by mail.postgresql.org (Postfix) with ESMTP id D0F77632AC1
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Thu, 22 Jul 2010 16:15:57 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia,
	port 10024) with ESMTP id 92202-08
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Thu, 22 Jul 2010 19:15:50 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from serenity.inversion.ee (serenity.inversion.ee [194.204.33.112])
	by mail.postgresql.org (Postfix) with ESMTP id 984EA63250C
	for <pgsql-performance@postgresql.org>;
	Thu, 22 Jul 2010 16:15:49 -0300 (ADT)
Received: by serenity.inversion.ee (Postfix, from userid 108)
	id 79E03E3444F; Thu, 22 Jul 2010 20:57:30 +0300 (EEST)
Received: from [IPv6:::1] (localhost [127.0.0.1])
	by serenity.inversion.ee (Postfix) with ESMTP id 69735E343A0;
	Thu, 22 Jul 2010 20:57:28 +0300 (EEST)
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
From: Hannu Krosing <hannu@krosing.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Craig Ringer <craig@postnewspapers.com.au>,
	Matthew Wakeling <matthew@flymine.org>, pgsql-performance@postgresql.org
In-Reply-To: <AANLkTinDgkzqf_=O+hk5OMq+AxN4G+fpfQZM4DBizAOF@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>
	<4C38BF03.6060503@agliodbs.com> <19244.1278787866@sss.pgh.pa.us>
	<alpine.DEB.2.00.1007121044330.2534@aragorn.flymine.org>
	<4C3AF564.5030204@postnewspapers.com.au>
	<AANLkTinDgkzqf_=O+hk5OMq+AxN4G+fpfQZM4DBizAOF@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 22 Jul 2010 20:15:44 +0100
Message-ID: <1279826144.14271.5.camel@hvost>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9
X-Spam-Level: 
X-Archive-Number: 201007/328
X-Sequence-Number: 39717

On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote:
> On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
> <craig@postnewspapers.com.au> wrote:
> > 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?"
> 
> Avoid sending every connection through an extra hop.

not really. in-core != magically-in-right-backend-process


there will still be "an extra hop",only it will be local, between pooler
and backend process.

similar to what currently happens with pgbouncer when you deploy it on
same server and use unix sockets

> 
> -- 
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise Postgres Company
>