Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 335712E0035 for ; Wed, 28 May 2008 20:26:48 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 40763-02 for ; Wed, 28 May 2008 20:26:39 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from master.phlo.org (master.phlo.org [213.147.174.89]) by developer.postgresql.org (Postfix) with ESMTP id 698842E0033 for ; Wed, 28 May 2008 20:26:43 -0300 (ADT) Received: (qmail 23332 invoked by uid 0); 28 May 2008 23:26:39 -0000 Received: from 091-141-098-114.dyn.one.at (fgp@[91.141.98.114]) (envelope-sender ) by imap.phlo.org (qmail-ldap-1.03) with SMTP for ; 28 May 2008 23:26:39 -0000 Message-ID: <483DEA2D.3010704@phlo.org> Date: Thu, 29 May 2008 01:26:37 +0200 From: "Florian G. Pflug" User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Simon Riggs CC: pgsql-hackers Subject: Re: Hint Bits and Write I/O References: <1211916951.4489.232.camel@ebony.site> <483C7CE8.2090404@phlo.org> <1211926242.4489.301.camel@ebony.site> In-Reply-To: <1211926242.4489.301.camel@ebony.site> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200805/888 X-Sequence-Number: 118887 Simon Riggs wrote: > Hmm, I think the question is: How many hint bits need to be set > before we mark the buffer dirty? (N) > > Should it be 1, as it is now? Should it be never? Never is a long > time. As N increases, clog accesses increase. So it would seem there > is likely to be an optimal value for N. After further thought, I begin to think that the number of times we set a dirty hint-bit shouldn't influence the decision of whether to dirty the page too much. Instead, we should look at the *age* of the last xid which modified the tuple. The idea is that the clog pages showing the status of "young" xids are far more likely to be cached that the pages for "older" xids. This makes a lost hint-bit update much cheaper for young than for old xids, because we probably won't waste any IO if we have to set the hint-bit again later, because the buffer was evicted from shared_buffers before being written out. Additionally, I think we should put some randomness into the decision, to spread the IO caused by hit-bit updates after a batch load. All in all, I envision a formula like chance_of_dirtying = min(1, alpha *floor((next_xid - last_modifying_xid)/clog_page_size) /clog_buffers ) This means that a hint-bit update never triggers dirtying if the last modifying xid belongs to the same clog page as the next unused xid - which sounds good, since that clog page gets touched on every commit and abort, and therefore is cached nearly for sure. For xids on older pages, the chance of dirtying grows (more aggresivly for larger alpha values). For alpha = 1, a hint-bit update dirties a buffer for sure only if the xid is older than clog_page_size*clog_buffers. regards, Florian Pflug