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 A1F629DCA30 for ; Wed, 1 Feb 2006 01:53:18 -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 61605-06 for ; Wed, 1 Feb 2006 01:53:17 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.mi8.com (d01gw04.mi8.com [63.240.6.44]) by postgresql.org (Postfix) with ESMTP id 4A4B99DC861 for ; Wed, 1 Feb 2006 01:53:15 -0400 (AST) Received: from 172.16.1.25 by mail.mi8.com with ESMTP (- Welcome to Mi8 Corporation www.Mi8.com (D4)); Wed, 01 Feb 2006 00:53:08 -0500 X-Server-Uuid: C8FB4D43-1108-484A-A898-3CBCC7906230 Received: from MI8NYCMAIL06.Mi8.com ([172.16.1.175]) by D01HOST03.Mi8.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 00:53:08 -0500 Received: from 69.181.100.71 ([69.181.100.71]) by MI8NYCMAIL06.Mi8.com ( [172.16.1.219]) via Exchange Front-End Server mi8owa.mi8.com ( [172.16.1.105]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Feb 2006 05:53:07 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 31 Jan 2006 21:53:06 -0800 Subject: Re: Huge Data sets, simple queries From: "Luke Lonergan" To: "Jeffrey W. Baker" cc: pgsql-performance@postgresql.org Message-ID: Thread-Topic: [PERFORM] Huge Data sets, simple queries Thread-Index: AcYm5VcOVl+TP4B0TpC35mjjGG9dFgADm6Aw In-Reply-To: <1138766980.14051.24.camel@noodles> MIME-Version: 1.0 X-OriginalArrivalTime: 01 Feb 2006 05:53:08.0510 (UTC) FILETIME=[C70D8BE0:01C626F3] X-WSS-ID: 6FFE934E20C2080458-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=1.349 required=5 tests=[AWL=0.096, RCVD_NUMERIC_HELO=1.253] X-Spam-Score: 1.349 X-Spam-Level: * X-Archive-Number: 200602/6 X-Sequence-Number: 16992 Jeffrey, On 1/31/06 8:09 PM, "Jeffrey W. Baker" wrote: >> ... Prove it. > I think I've proved my point. Software RAID1 read balancing provides > 0%, 300%, 100%, and 100% speedup on 1, 2, 4, and 8 threads, > respectively. In the presence of random I/O, the results are even > better. > Anyone who thinks they have a single-threaded workload has not yet > encountered the autovacuum daemon. Good data - interesting case. I presume from your results that you had to make the I/Os non-overlapping (the "skip" option to dd) in order to get the concurrent access to work. Why the particular choice of offset - 3.2GB in this case? So - the bandwidth doubles in specific circumstances under concurrent workloads - not relevant to "Huge Data sets, simple queries", but possibly helpful for certain kinds of OLTP applications. - Luke