X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 93C749FB2AF for ; Wed, 20 Sep 2006 14:06:10 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 44012-01-9 for ; Wed, 20 Sep 2006 17:05:47 +0000 (UTC) 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 83C5D9FB2F2 for ; Wed, 20 Sep 2006 14:04:31 -0300 (ADT) Received: from 172.16.1.110 by mail.mi8.com with ESMTP (- Welcome to Mi8 Corporation www.Mi8.com (D4)); Wed, 20 Sep 2006 13:04:16 -0400 X-Server-Uuid: C8FB4D43-1108-484A-A898-3CBCC7906230 Received: from MI8NYCMAIL06.Mi8.com ([172.16.1.175]) by D01SMTP01.Mi8.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 13:03:58 -0400 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.106]) with Microsoft Exchange Server HTTP-DAV ; Wed, 20 Sep 2006 17:03:58 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 20 Sep 2006 10:03:58 -0700 Subject: Re: Large tables (was: RAID 0 not as fast as From: "Luke Lonergan" To: "Markus Schaber" , pgsql-performance@postgresql.org Message-ID: Thread-Topic: [PERFORM] Large tables (was: RAID 0 not as fast as Thread-Index: Acbc1sMKAWyCNEjKEdu76AAWy4o9DA== In-Reply-To: <4510F720.5010007@logix-tt.com> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Sep 2006 17:03:58.0620 (UTC) FILETIME=[C3692DC0:01C6DCD6] X-WSS-ID: 690FAB042US9288352-17-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200609/271 X-Sequence-Number: 20957 Markus, On 9/20/06 1:09 AM, "Markus Schaber" wrote: > Do you think that adding some posix_fadvise() calls to the backend to > pre-fetch some blocks into the OS cache asynchroneously could improve > that situation? Nope - this requires true multi-threading of the I/O, there need to be multiple seek operations running simultaneously. The current executor blocks on each page request, waiting for the I/O to happen before requesting the next page. The OS can't predict what random page is to be requested next. We can implement multiple scanners (already present in MPP), or we could implement AIO and fire off a number of simultaneous I/O requests for fulfillment. - Luke