Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 7568E630E25 for ; Mon, 12 Jan 2009 01:20:20 -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 95945-07 for ; Mon, 12 Jan 2009 01:20:17 -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 2233262D561 for ; Mon, 12 Jan 2009 01:20:16 -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 n0C5JghT013518; Mon, 12 Jan 2009 00:19:42 -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: Mon, 12 Jan 2009 00:19:42 -0500 Message-ID: <13517.1231737582@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/818 X-Sequence-Number: 131462 "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 applied most of this, with a couple of notable revisions: 1. The runtime check on whether posix_fadvise works is really gone. We'll see whether we need to put anything back, but I think our first try should be under the assumption that it works. (BTW, I was wrong in my earlier claim that the buildfarm wouldn't exercise posix_fadvise by default --- the patch defaults to io_concurrency = 1 if fadvise is available, so it will try to prefetch one page ahead.) 2. I fixed it so that setting effective_io_concurrency to zero disables prefetching altogether; there was no way to do that in the patch as submitted. 3. I did not apply the changes in nbtsearch.c, since as I mentioned earlier I wasn't convinced it's a reasonable approach. We can argue about that some more, but even if 8.4 ships with concurrency only for bitmap scans, it's still useful. The two main loose ends that could stand further work are the plain-index-scan case and the question of whether PrefetchBuffer should try to protect an already-existing buffer from being evicted. regards, tom lane