Date: Fri, 24 Mar 2006 14:21:24 -0500
From: Michael Stone <mstone+postgres@mathom.us>
Subject: Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
In-reply-to: <60zmjfsnz0.fsf@dba2.int.libertyrms.com>
To: pgsql-performance@postgresql.org
Mail-followup-to: pgsql-performance@postgresql.org
Message-id: <20060324192122.GJ15140@mathom.us>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-disposition: inline
References: <65f9ddfb0603222219r1742c2aevda37acd55ca845be@mail.gmail.com>
	<1143131901.17999.67.camel@state.g2switchworks.com>
	<4422D033.2030407@commandprompt.com>
	<1143133364.17999.77.camel@state.g2switchworks.com>
	<87hd5olgyd.fsf@wolfe.cbbrowne.com>
	<20060324101440.GP90527@pervasive.com>
	<60zmjfsnz0.fsf@dba2.int.libertyrms.com>
User-Agent: Mutt/1.5.11+cvs20060126

On Fri, Mar 24, 2006 at 01:21:23PM -0500, Chris Browne wrote:
>A naive read on this is that you might start with one backend process,
>which then spawns 16 more.  Each of those backends is scanning through
>one of those 16 files; they then throw relevant tuples into shared
>memory to be aggregated/joined by the central one.

Of course, table scanning is going to be IO limited in most cases, and 
having every query spawn 16 independent IO threads is likely to slow 
things down in more cases than it speeds them up. It could work if you 
have a bunch of storage devices, but at that point it's probably easier 
and more direct to implement a clustered approach.

Mike Stone