Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 95A91650034 for ; Sat, 2 Aug 2008 01:26:40 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 89924-03 for ; Sat, 2 Aug 2008 01:26:19 -0300 (ADT) 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 postgresql.org (Postfix) with ESMTP id 9E2EE650010 for ; Sat, 2 Aug 2008 01:25:07 -0300 (ADT) 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 m724OkrV027350; Sat, 2 Aug 2008 00:24:47 -0400 (EDT) To: Alvaro Herrera cc: Simon Riggs , List pgsql-patches Subject: Re: [HACKERS] Hint Bits and Write I/O In-reply-to: <20080801231014.GM4321@alvh.no-ip.org> References: <1211916951.4489.232.camel@ebony.site> <15901.1211931165@sss.pgh.pa.us> <1213797209.9468.126.camel@ebony.site> <87hcbfq71p.fsf@oxford.xeocode.com> <1214578938.3845.423.camel@ebony.site> <1214865781.3845.525.camel@ebony.site> <20080801231014.GM4321@alvh.no-ip.org> Comments: In-reply-to Alvaro Herrera message dated "Fri, 01 Aug 2008 19:10:14 -0400" Date: Sat, 02 Aug 2008 00:24:46 -0400 Message-ID: <27349.1217651086@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: 200808/3 X-Sequence-Number: 6979 Alvaro Herrera writes: > I think it makes sense to commit this patch now, per previous > discussions on which we have agreed to make incremental changes. Yeah, but at the same time there is merit in the argument that the proposed patch hasn't actually been proven to be usable for anything. I would be a lot happier if there were even a trivial proof-of-concept plugin example submitted with it, just to prove that there were no showstopper problems in the plugin design, like failure to pass essential information or not getting the locking straight. > I'm just wondering if the change of usage_count from 16 to 8 bits was > discussed and agreed? Umm ... it was not, but given that we have logic in there to limit the usage_count to 5 or so, it's hard to argue that there's a big problem. I confess to not having read the patch in detail --- where did the other 8 bits go to? regards, tom lane