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 AAA0F9DCA80 for ; Thu, 2 Feb 2006 15:41:32 -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 85500-10 for ; Thu, 2 Feb 2006 15:41:30 -0400 (AST) Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id B33C69DCA6D for ; Thu, 2 Feb 2006 15:41:28 -0400 (AST) Received: from unicorn.rentec.com (unicorn.rentec.com [216.223.240.9]) by svr4.postgresql.org (Postfix) with ESMTP id 14C6C5AF1FA for ; Thu, 2 Feb 2006 19:41:29 +0000 (GMT) Received: from ram.rentec.com (mailhost [192.5.35.66]) by unicorn.rentec.com (8.13.1/8.12.1) with ESMTP id k12JfJhf024755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2006 14:41:21 -0500 (EST) X-Source: non-mednet Received: from [172.26.132.145] (hoopoe.rentec.com [172.26.132.145]) by ram.rentec.com (8.13.1/8.12.1) with ESMTP id k12JfJ0v027014; Thu, 2 Feb 2006 14:41:19 -0500 (EST) Message-ID: <43E2605F.5050705@rentec.com> Date: Thu, 02 Feb 2006 14:41:19 -0500 From: Alan Stange Reply-To: stange@rentec.com Organization: Renaissance Technologies Corp. User-Agent: Thunderbird 1.6a1 (X11/20060106) MIME-Version: 1.0 To: "Jeffrey W. Baker" Cc: pgsql-performance@postgresql.org Subject: Re: Huge Data sets, simple queries References: <1138737838.5648.4.camel@toonses.gghcwest.com> In-Reply-To: <1138737838.5648.4.camel@toonses.gghcwest.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Logged: Logged by unicorn.rentec.com as k12JfJhf024755 at Thu Feb 2 14:41:21 2006 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.037 required=5 tests=[AWL=0.037] X-Spam-Score: 0.037 X-Spam-Level: X-Archive-Number: 200602/42 X-Sequence-Number: 17028 Jeffrey W. Baker wrote: > On Tue, 2006-01-31 at 09:00 -0800, Luke Lonergan wrote: > >> Jim, >> >> On 1/30/06 12:25 PM, "Jim C. Nasby" wrote: >> >> >>> Why divide by 2? A good raid controller should be able to send read >>> requests to both drives out of the mirrored set to fully utilize the >>> bandwidth. Of course, that probably won't come into play unless the OS >>> decides that it's going to read-ahead fairly large chunks of the table >>> at a time... >>> >> I've not seen one that does, nor would it work in the general case IMO. In >> RAID1 writes are duplicated and reads come from one of the copies. You >> could alternate read service requests to minimize rotational latency, but >> you can't improve bandwidth. >> > > Then you've not seen Linux. Linux does balanced reads on software > mirrors. I'm not sure why you think this can't improve bandwidth. It > does improve streaming bandwidth as long as the platter STR is more than > the bus STR. > FYI: so does the Solaris Volume Manager (by default) on Solaris. One can choose alternate access methods like "First" (if the other mirrors are slower than the first) or "Geometric". It's been doing this for a good 10 years now (back when it was called DiskSuite), so it's nothing new. -- Alan