Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 146606323D4 for ; Sun, 11 Jan 2009 16:41:41 -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 56758-01 for ; Sun, 11 Jan 2009 16:41:38 -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 32E316323CD for ; Sun, 11 Jan 2009 16:41:38 -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 n0BKf2TK002084; Sun, 11 Jan 2009 15:41:03 -0500 (EST) To: "Robert Haas" cc: "Gregory Stark" , "ITAGAKI Takahiro" , Postgres Subject: Re: posix_fadvise v22 In-reply-to: <603c8f070901111145n720e0abdwb95720d1651d63b0@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> <1098.1231701290@sss.pgh.pa.us> <603c8f070901111145n720e0abdwb95720d1651d63b0@mail.gmail.com> Comments: In-reply-to "Robert Haas" message dated "Sun, 11 Jan 2009 14:45:26 -0500" Date: Sun, 11 Jan 2009 15:41:02 -0500 Message-ID: <2083.1231706462@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/813 X-Sequence-Number: 131457 "Robert Haas" writes: > FWIW, following your first set of commits, I extracted, cleaned up, > and re-posted the uncommitted portion of the patch last night. Based > on this it doesn't sound like there's much point in continuing to do > that, but I'm happy to do so if anyone thinks otherwise. Probably not; I'm busy hacking on the code anyway, fixing minor issues like its failure to do anything sane with temp tables. A question about that part of the code: I see that PrefetchBuffer simply does nothing if it finds the target page already in a buffer. I wonder whether that's sufficient, or whether we ought to do something to try to ensure that the buffer doesn't get evicted in the near future (ie, before we actually get to use it). Simply advancing the usage_count seems too strong because when you add in the upcoming ReadBuffer, we'd be advancing usage_count twice for a single use of the page whenever it happened to get prefetched. We could alleviate that by only advancing usage_count if it's 0, but that seems like a band-aid not a real fix. I also thought about setting a buffer flag bit showing that prefetch has occurred, but then you have to worry about when/how to clear it if the actual read never occurs. Thoughts? regards, tom lane