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 5DEF9DBB20 for ; Fri, 18 Nov 2005 22:27:50 -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 24899-05 for ; Sat, 19 Nov 2005 02:27:53 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from linda-3.paradise.net.nz (bm-3a.paradise.net.nz [203.96.152.182]) by svr1.postgresql.org (Postfix) with ESMTP id C02DADBAC8 for ; Fri, 18 Nov 2005 22:27:47 -0400 (AST) Received: from smtp-2.paradise.net.nz (tclsnelb2-src-1.paradise.net.nz [203.96.152.177]) by linda-3.paradise.net.nz (Paradise.net.nz) with ESMTP id <0IQ6004RJK6FAK@linda-3.paradise.net.nz> for pgsql-performance@postgresql.org; Sat, 19 Nov 2005 15:27:51 +1300 (NZDT) Received: from [192.168.1.11] (218-101-29-15.dsl.clear.net.nz [218.101.29.15]) by smtp-2.paradise.net.nz (Postfix) with ESMTP id 2249BC3DC2F; Sat, 19 Nov 2005 15:27:51 +1300 (NZDT) Date: Sat, 19 Nov 2005 15:27:49 +1300 From: Mark Kirkwood Subject: Re: Hardware/OS recommendations for large databases ( In-reply-to: To: Luke Lonergan Cc: Dave Cramer , Greg Stark , Joshua Marsh , pgsql-performance@postgresql.org Message-id: <437E8DA5.1050703@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051106) References: X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=1.332 required=5 tests=[RCVD_IN_BL_SPAMCOP_NET=1.332] X-Spam-Score: 1.332 X-Spam-Level: * X-Archive-Number: 200511/388 X-Sequence-Number: 15645 Luke Lonergan wrote: > Mark, > > On 11/18/05 3:46 PM, "Mark Kirkwood" wrote: > > If you alter this to involve more complex joins (e.g 4. way star) and > (maybe add a small number of concurrent executors too) - is it still the > case? > > > I may not have listened to you - are you asking about whether the > readahead works for these cases? > > I’ll be running some massive TPC-H benchmarks on these machines soon – > we’ll see then. That too, meaning the business of 1 executor random reading a given relation file whilst another is sequentially scanning (some other) part of it.... Cheers Mark