Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 066526332E4 for ; Tue, 27 Jul 2010 17:40:22 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 65955-02 for ; Tue, 27 Jul 2010 20:40:13 +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 93860633283 for ; Tue, 27 Jul 2010 17:40:14 -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 o6RKe2BE013655; Tue, 27 Jul 2010 16:40:02 -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> Comments: In-reply-to Robert Haas message dated "Thu, 22 Jul 2010 21:00:57 -0400" Date: Tue, 27 Jul 2010 16:40:02 -0400 Message-ID: <13654.1280263202@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/414 X-Sequence-Number: 39803 Robert Haas writes: > On Thu, Jul 22, 2010 at 5:29 PM, Andres Freund wrote: >>> The problem is harder for us because a backend can't switch identities >>> once it's been assigned to a database.  I haven't heard an adequate >>> explanation of why that couldn't be changed, though. >> Possibly it might decrease the performance significantly enough by >> reducing the cache locality (syscache, prepared plans)? > Those things are backend-local. The worst case scenario is you've got > to flush them all when you reinitialize, in which case you still save > the overhead of creating a new process. "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. What's much worse, it's not zero-bug. We've got little bitty caches all over the backend, including (no doubt) some caching behavior in third-party code that wouldn't get the word about whatever API you invented to deal with this. regards, tom lane