Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id EA00F635908 for ; Fri, 23 Jul 2010 13:53:11 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 94252-09-2 for ; Fri, 23 Jul 2010 16:53:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from spinlock.commandprompt.com (host-215.commandprompt.net [207.173.203.215]) by mail.postgresql.org (Postfix) with ESMTP id 6E3D4634E47 for ; Fri, 23 Jul 2010 13:52:58 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by spinlock.commandprompt.com (Postfix) with ESMTP id 06F7634C211; Fri, 23 Jul 2010 09:52:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at commandprompt.com Received: from spinlock.commandprompt.com ([127.0.0.1]) by localhost (spinlock.commandprompt.com.commandprompt.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hq6+FcM4owBx; Fri, 23 Jul 2010 09:52:54 -0700 (PDT) Received: from [75.142.153.107] (unknown [75.142.153.107]) by spinlock.commandprompt.com (Postfix) with ESMTPSA id 86D7734C210; Fri, 23 Jul 2010 09:52:54 -0700 (PDT) Subject: Re: Pooling in Core WAS: Need help in performance tuning. From: "Joshua D. Drake" Reply-To: jd@commandprompt.com To: Hannu Krosing Cc: Robert Haas , Craig Ringer , Matthew Wakeling , pgsql-performance@postgresql.org In-Reply-To: <1279828566.14271.16.camel@hvost> References: <4C369346.6010501@postnewspapers.com.au> <8760.1278650566@sss.pgh.pa.us> <1278680186.1914.36.camel@bnicholson-desktop> <4C36F57102000025000332F6@gw.wicourts.gov> <4C36FEAD02000025000332FC@gw.wicourts.gov> <4C37A9C1.1060405@2ndquadrant.com> <4C37791C0200002500033379@gw.wicourts.gov> <4C37CBFB.1000800@agliodbs.com> <4C37EA1D.6000008@postnewspapers.com.au> <4C38BF03.6060503@agliodbs.com> <19244.1278787866@sss.pgh.pa.us> <4C3AF564.5030204@postnewspapers.com.au> <1279826118.22360.137.camel@jd-desktop.unknown.charter.com> <1279828566.14271.16.camel@hvost> Content-Type: text/plain; charset="UTF-8" Organization: Command Prompt, Inc. Date: Fri, 23 Jul 2010 09:52:37 -0700 Message-ID: <1279903957.22360.190.camel@jd-desktop.unknown.charter.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 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/337 X-Sequence-Number: 39726 On Thu, 2010-07-22 at 20:56 +0100, Hannu Krosing wrote: > > > Let's extend this shall we: > > > > Avoid adding yet another network hop > > postgreSQL is multi-process, so you either have a separate "pooler > process" or need to put pooler functionality in postmaster, bothw ways > you still have a two-hop scenario for connect. you may be able to pass > the socket to child process and also keep it, but doing this for both > client and db sides seems really convoluted. Which means, right now there is three hops. Reducing one is good. > Or is there a prortable way to pass sockets back and forth between > parent and child processes ? > > If so, then pgbouncer could use it as well. > > > Remove of a point of failure > > rather move the point of failure from external pooler to internal > pooler ;) Yes but at that point, it doesn't matter. > > > Reduction of administrative overhead > > Possibly. But once you start actually using it, you still need to > configure and monitor it and do other administrator-y tasks. Yes, but it is inclusive. > > > Integration into our core authentication mechanisms > > True, although for example having SSL on client side connection will be > so slow that it hides any performance gains from pooling, at least for > short-lived connections. Yes, but right now you can't use *any* pooler with LDAP for example. We could if pooling was in core. Your SSL argument doesn't really work because its true with or without pooling. > > Greater flexibility in connection control > > Yes, poolers can be much more flexible than default postgresql. See for > example pgbouncers PAUSE , RECONFIGURE and RESUME commands :D > > > And, having connection pooling in core does not eliminate the use of an > > external pool where it makes since. > > Probably the easiest way to achieve "pooling in core" would be adding an > option to start pgbouncer under postmaster control. Yeah but that won't happen. Also I think we may have a libevent dependency that we have to work out. > > You probably can't get much leaner than pgbouncer. Oh don't get me wrong. I love pgbouncer. It is my recommended pooler but even it has limitations (such as auth). Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt