Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id E9F21632486 for ; Sun, 11 Jan 2009 15:15:33 -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 66446-01 for ; Sun, 11 Jan 2009 15:15:26 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 75A34632481 for ; Sun, 11 Jan 2009 15:15:26 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id n0BJEoAa001099; Sun, 11 Jan 2009 14:14:50 -0500 (EST) To: "Robert Haas" cc: "Gregory Stark" , "ITAGAKI Takahiro" , Postgres Subject: Re: posix_fadvise v22 In-reply-to: <603c8f070901011843p121e40afu35c4a7bdc51c051c@mail.gmail.com> 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> Comments: In-reply-to "Robert Haas" message dated "Thu, 01 Jan 2009 21:43:29 -0500" Date: Sun, 11 Jan 2009 14:14:50 -0500 Message-ID: <1098.1231701290@sss.pgh.pa.us> From: Tom Lane 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/807 X-Sequence-Number: 131451 "Robert Haas" writes: > OK, here's an update of Greg's patch with the runtime configure test > ripped out, some minor documentation tweaks, and a few unnecessary > whitespace diff hunks quashed. I think this is about ready for > committer review. I've started to look through this, and the only part I seriously don't like is the nbtsearch.c changes. I've got three complaints about that: * Doing it inside the index AMs is wrong, or at the very least forces us to do it over for each index AM (which the patch fails to do). * As coded, it generates prefetch bursts that are much too large and too widely spaced to be effective, not to mention that they entirely ignore the effective_io_concurrency control knob as well as the order in which the pages will actually be needed. I wonder now whether Robert's inability to see any benefit came because he was testing indexscans and not bitmap scans. * It's only accidental that it's not kicking in during a bitmap indexscan and bollixing up the much-more-carefully-written nodeBitmapHeapscan prefetch logic. What I intend to do over the next day or so is commit the prefetch infrastructure and the bitmap scan prefetch logic, but I'm bouncing the indexscan part back for rework. I think that it should be implemented in or near index_getnext() and pay attention to effective_io_concurrency. regards, tom lane