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 4DDF69DCC57 for ; Fri, 24 Mar 2006 16:04:09 -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 35548-10 for ; Fri, 24 Mar 2006 16:04:09 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from floppy.pyrenet.fr (news.pyrenet.fr [194.116.145.2]) by postgresql.org (Postfix) with ESMTP id B011D9DCC3B for ; Fri, 24 Mar 2006 16:04:03 -0400 (AST) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 4196E30BA0; Fri, 24 Mar 2006 21:04:03 +0100 (MET) From: Chris Browne X-Newsgroups: pgsql.performance Subject: Re: Scaling up PostgreSQL in Multiple CPU / Dual Core Date: Fri, 24 Mar 2006 14:33:21 -0500 Organization: cbbrowne Computing Inc Lines: 22 Message-ID: <60r74rskn2.fsf@dba2.int.libertyrms.com> 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> <20060324192122.GJ15140@mathom.us> 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:E61skgZ6X4hjsmecXlYU13nGW8k= To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.308 required=5 tests=[AWL=0.308] X-Spam-Score: 0.308 X-Spam-Level: X-Archive-Number: 200603/512 X-Sequence-Number: 17949 mstone+postgres@mathom.us (Michael Stone) writes: > 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. All stipulated, yes. It obviously wouldn't be terribly useful to scan more aggressively than I/O bandwidth can support. The point is that this is one of the kinds of places where concurrent processing could do some good... -- let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;; http://cbbrowne.com/info/spiritual.html Save the whales. Collect the whole set.