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: Wed, 28 Jul 2010 01:09:34 -0400
Message-ID: <3774.1280293774@sss.pgh.pa.us> (raw)
In-Reply-To: <AANLkTinVRnEekXJTik==RROvfXX89cL4Uc3wcq-VKvc2@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>
	<20776.1280282217@sss.pgh.pa.us>
	<AANLkTinVRnEekXJTik==RROvfXX89cL4Uc3wcq-VKvc2@mail.gmail.com>

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jul 27, 2010 at 9:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> I agree that the gain is minimal of itself; after all, how often do
> you need to switch databases, and what's the big deal if the
> postmaster has to fork a new backend?  Where I see it as a potentially
> big win is when it comes to things like parallel query.  I can't help
> thinking that's going to be a lot less efficient if you're forever
> forking new backends.

Color me unconvinced.  To do parallel queries with pre-existing worker
processes, you'd need to hook up with a worker that was (at least) in
your own database, and then somehow feed it the query plan that it needs
to execute.  I'm thinking fork() could easily be cheaper.  But obviously
this is all speculation (... and Windows is going to be a whole 'nother
story in any case ...)

			regards, tom lane



view thread (59+ messages)  latest in thread

Message-ID: <3774.1280293774@sss.pgh.pa.us>
Permalink:  ../3774.1280293774@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/3774.1280293774@sss.pgh.pa.us

 · 

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: <3774.1280293774@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