Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 13DA4632ADA for ; Tue, 27 Jul 2010 22:57:13 -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 41274-05 for ; Wed, 28 Jul 2010 01:57:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id E7410632C51 for ; Tue, 27 Jul 2010 22:57:05 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o6S1uvlN020778; Tue, 27 Jul 2010 21:56:57 -0400 (EDT) To: Robert Haas cc: Andres Freund , Craig Ringer , Matthew Wakeling , pgsql-performance@postgresql.org Subject: Re: Pooling in Core WAS: Need help in performance tuning. In-reply-to: References: <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> <20100722212954.GA16758@anarazel.de> <13654.1280263202@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Tue, 27 Jul 2010 21:44:40 -0400" Date: Tue, 27 Jul 2010 21:56:57 -0400 Message-ID: <20776.1280282217@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201007/421 X-Sequence-Number: 39810 Robert Haas writes: > On Tue, Jul 27, 2010 at 4:40 PM, Tom Lane wrote: >> "Flushing them all" is not zero-cost; it's not too hard to believe that >> it could actually be slower than forking a clean new backend. > I'm not so sure I believe that. I'm not asserting it's true, just suggesting it's entirely possible. Other than the fork() cost itself and whatever authentication activity there might be, practically all the startup cost of a new backend can be seen as cache-populating activities. You'd have to redo all of that, *plus* pay the costs of getting rid of the previous cache entries. Maybe the latter costs less than a fork(), or maybe not. fork() is pretty cheap on modern Unixen. >> What's much worse, it's not zero-bug. > I think this is probably the biggest issue with the whole idea, and I > agree there would be some pain involved. Yeah, if it weren't for that I'd say "sure let's try it". But I'm afraid we'd be introducing significant headaches in return for a gain that's quite speculative. regards, tom lane