pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feed From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Craig Ringer <craig@postnewspapers.com.au>
Cc: Matthew Wakeling <matthew@flymine.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
Date: Tue, 27 Jul 2010 21:56:57 -0400
Message-ID: <20776.1280282217@sss.pgh.pa.us> (raw )
In-Reply-To: <AANLkTi=KtADzPgBSnfmPfk2YwoMaZ2=iq8BAtYbxjO8B@mail.gmail.com >
References: <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 >
<AANLkTikG_QqNXmGaAtnChGHyVAhdSosoE5M3MXwDKMH8@mail.gmail.com >
<20100722212954.GA16758@anarazel.de >
<AANLkTinnxNM2vOwB6-tkBhCQ=6+xChOfdjrofDEpxYxk@mail.gmail.com >
<13654.1280263202@sss.pgh.pa.us >
<AANLkTi=KtADzPgBSnfmPfk2YwoMaZ2=iq8BAtYbxjO8B@mail.gmail.com >
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jul 27, 2010 at 4:40 PM, Tom Lane <tgl@sss.pgh.pa.us> 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
view thread (59+ messages) latest in thread
Message-ID: <20776.1280282217@sss.pgh.pa.us>
Permalink: ../20776.1280282217@sss.pgh.pa.us/
Also on: postgresql.org/message-id/20776.1280282217@sss.pgh.pa.us
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, andres@anarazel.de, craig@postnewspapers.com.au, matthew@flymine.org
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
In-Reply-To: <20776.1280282217@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox