Skip site navigation (1) Skip section navigation (2)

Re: Scaling up PostgreSQL in Multiple CPU / Dual Core

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
Date: 2006-03-24 18:24:09
Message-ID: 60veu3snue.fsf@dba2.int.libertyrms.com (view raw or flat)
Thread:
Lists: pgsql-performance
llonergan(at)greenplum(dot)com ("Luke Lonergan") writes:
> Christopher,
>
> On 3/23/06 6:22 PM, "Christopher Browne" <cbbrowne(at)acm(dot)org> wrote:
>
>> Question: Does the Bizgress/MPP use threading for this concurrency?
>> Or forking?
>> 
>> If it does so via forking, that's more portable, and less dependent on
>> specific complexities of threading implementations (which amounts to
>> non-portability ;-)).
>
> OK - I'll byte:
>
> It's process based, we fork backends at slice points in the execution plan.

By "slice points", do you mean that you'd try to partition tables
(e.g. - if there's a Seq Scan on a table with 8 1GB segments, you
could spawn as many as 8 processes), or that two scans that are then
merge joined means a process for each scan, and a process for the
merge join?  Or perhaps both :-).  Or perhaps something else entirely ;-).

> To take care of the startup latency problem, we persist sets of
> these backends, called "gangs".  They appear, persist for connection
> scope for reuse, then are disbanded.

If only that could happen to more gangs...
-- 
output = ("cbbrowne" "@" "cbbrowne.com")
http://cbbrowne.com/info/multiplexor.html
"I'm sorry, the teleportation booth you have reached is not in service
at this  time.   Please  hand-reassemble  your molecules or   call  an
operator to help you...."

In response to

pgsql-performance by date

Next:From: Svenne KrapDate: 2006-03-24 19:16:29
Subject: Re: Performance problems with multiple layers of functions
Previous:From: Chris BrowneDate: 2006-03-24 18:21:23
Subject: Re: Scaling up PostgreSQL in Multiple CPU / Dual Core

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group