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 AD87311F6AE7 for ; Sun, 9 Apr 2006 17:24:59 -0300 (ADT) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Score: 0.12 X-Spam-Level: X-Spam-Status: No, score=0.12 required=5 tests=[AWL=0.120] Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id X-IEVr4PZ8Hj for ; Sun, 9 Apr 2006 17:24:48 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from candle.pha.pa.us (candle.pha.pa.us [70.90.9.53]) by postgresql.org (Postfix) with ESMTP id 0A9A011F6922 for ; Sun, 9 Apr 2006 17:24:49 -0300 (ADT) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.11.6) id k39KOjR15478; Sun, 9 Apr 2006 16:24:45 -0400 (EDT) From: Bruce Momjian Message-Id: <200604092024.k39KOjR15478@candle.pha.pa.us> Subject: Re: Scaling up PostgreSQL in Multiple CPU / Dual Core In-Reply-To: <60r74rskn2.fsf@dba2.int.libertyrms.com> To: Chris Browne Date: Sun, 9 Apr 2006 16:24:44 -0400 (EDT) CC: pgsql-performance@postgresql.org X-Mailer: ELM [version 2.4ME+ PL121 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Archive-Number: 200604/180 X-Sequence-Number: 18264 Added to TODO: * Experiment with multi-threaded backend better resource utilization This would allow a single query to make use of multiple CPU's or multiple I/O channels simultaneously. --------------------------------------------------------------------------- Chris Browne wrote: > 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. > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian http://candle.pha.pa.us + If your life is a hard drive, Christ can be your backup. +