X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 102E6DBBA2 for ; Sat, 19 Nov 2005 12:15:45 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 37611-09 for ; Sat, 19 Nov 2005 16:15:43 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.mi8.com (d01gw04.mi8.com [63.240.6.44]) by svr1.postgresql.org (Postfix) with ESMTP id 4B92ADBB96 for ; Sat, 19 Nov 2005 12:15:42 -0400 (AST) Received: from 172.16.1.112 by mail.mi8.com with ESMTP (- Welcome to Mi8 Corporation www.Mi8.com (D4)); Sat, 19 Nov 2005 11:15:31 -0500 X-Server-Uuid: C8FB4D43-1108-484A-A898-3CBCC7906230 Received: from MI8NYCMAIL06.Mi8.com ([172.16.1.175]) by D01SMTP02.Mi8.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 19 Nov 2005 11:15:31 -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.104]) with Microsoft Exchange Server HTTP-DAV ; Sat, 19 Nov 2005 11:15:30 -0500 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sat, 19 Nov 2005 08:15:29 -0800 Subject: Re: Hardware/OS recommendations for large databases ( From: "Luke Lonergan" To: "Mark Kirkwood" cc: "Dave Cramer" , "Greg Stark" , "Joshua Marsh" , pgsql-performance@postgresql.org Message-ID: Thread-Topic: [PERFORM] Hardware/OS recommendations for large databases ( Thread-Index: AcXssN0ZViVaQXB4RgWzT+CnPb8m7gAc5gMJ In-Reply-To: <437E8DA5.1050703@paradise.net.nz> MIME-Version: 1.0 X-OriginalArrivalTime: 19 Nov 2005 16:15:31.0170 (UTC) FILETIME=[7671C420:01C5ED24] X-WSS-ID: 6F61902931S15625257-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.253 required=5 tests=[AWL=0.000, RCVD_NUMERIC_HELO=1.253] X-Spam-Score: 1.253 X-Spam-Level: * X-Archive-Number: 200511/400 X-Sequence-Number: 15657 Mark, On 11/18/05 6:27 PM, "Mark Kirkwood" wrote: > That too, meaning the business of 1 executor random reading a given > relation file whilst another is sequentially scanning (some other) part > of it.... I think it should actually improve things - each I/O will read 16MB into the I/O cache, then the next scanner will seek for 10ms to get the next 16MB into cache, etc. It should minimize the seek/data ratio nicely. As long as the tables are contiguous it should rock and roll. - Luke