X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 9CB729DCC1F for ; Fri, 24 Mar 2006 15:04:10 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 14735-10 for ; Fri, 24 Mar 2006 15:04:10 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from floppy.pyrenet.fr (floppy.pyrenet.fr [194.116.145.2]) by postgresql.org (Postfix) with ESMTP id AF1FC9DCD90 for ; Fri, 24 Mar 2006 15:04:04 -0400 (AST) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 0F6B630BA1; Fri, 24 Mar 2006 20:04:04 +0100 (MET) From: Chris Browne X-Newsgroups: pgsql.performance Subject: Re: Scaling up PostgreSQL in Multiple CPU / Dual Core Date: Fri, 24 Mar 2006 13:24:09 -0500 Organization: cbbrowne Computing Inc Lines: 33 Message-ID: <60veu3snue.fsf@dba2.int.libertyrms.com> References: <87hd5olgyd.fsf@wolfe.cbbrowne.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@news.hub.org User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (linux) Cancel-Lock: sha1:V+h2Kfka1HlF2BRoUsXudOQfTtA= To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.311 required=5 tests=[AWL=0.311] X-Spam-Score: 0.311 X-Spam-Level: X-Archive-Number: 200603/507 X-Sequence-Number: 17944 llonergan@greenplum.com ("Luke Lonergan") writes: > Christopher, > > On 3/23/06 6:22 PM, "Christopher Browne" 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...."