Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 69B6764FD1A for ; Fri, 2 Jan 2009 19:02:26 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 36313-09 for ; Fri, 2 Jan 2009 19:02:20 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-bw0-f19.google.com (mail-bw0-f19.google.com [209.85.218.19]) by mail.postgresql.org (Postfix) with ESMTP id DF40564FCF2 for ; Fri, 2 Jan 2009 19:02:19 -0400 (AST) Received: by bwz12 with SMTP id 12so17673217bwz.19 for ; Fri, 02 Jan 2009 15:02:18 -0800 (PST) Received: by 10.223.113.199 with SMTP id b7mr13107473faq.83.1230937337896; Fri, 02 Jan 2009 15:02:17 -0800 (PST) Received: by 10.223.115.79 with HTTP; Fri, 2 Jan 2009 15:02:17 -0800 (PST) Message-ID: <4136ffa0901021502w78f0611dx63929ac0fbbdc2f4@mail.gmail.com> Date: Fri, 2 Jan 2009 18:02:17 -0500 From: "Greg Stark" To: "Robert Haas" Subject: Re: posix_fadvise v22 Cc: "Greg Smith" , "Tom Lane" , "ITAGAKI Takahiro" , Postgres In-Reply-To: <603c8f070901021436v71f10188g1d747b493c89f2f5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8347.1229012970@sss.pgh.pa.us> <4136ffa0812110911x4914a951o6ca502879e3dede7@mail.gmail.com> <87k5a6tmy7.fsf@oxford.xeocode.com> <603c8f070901011230t1afa6644racb715b975078054@mail.gmail.com> <10658.1230843315@sss.pgh.pa.us> <603c8f070901011843p121e40afu35c4a7bdc51c051c@mail.gmail.com> <603c8f070901021436v71f10188g1d747b493c89f2f5@mail.gmail.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200901/82 X-Sequence-Number: 130726 On Fri, Jan 2, 2009 at 5:36 PM, Robert Haas wrote: >> I've got a stack of hardware I can do performance testing of this patch on, >> what I haven't been able to find time for is setting up any sort of test >> harness right now. If you or Greg have any benchmark or test program you >> could suggest that should show off the improvements here, I'd be glad to run >> it on a bunch of systems and report back--I've already got a stack of >> candidate ones I ran the earlier tests on to compare results against. > > Then I made an index on one of the columns and ran some queries that > ended up being planned as bitmap index scans. Hm, what were those plans? You might want to put the old code back in explain.c to print the prefetching target to see how well it's doing. The queries I ran to test it tended to look like this kind of thing, where r was a column filled with random values. If it's clustered there will be hardly any benefit as even random i/o would be prefetched by the OS. select * from h where r = any (array(select (1+random()*2000000)::integer from generate_series(1,1000))); -- greg