Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 517832E003A for ; Tue, 27 May 2008 16:33:35 -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 25642-01 for ; Tue, 27 May 2008 16:33:24 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail136079.authsmtp.co.uk (outmail136079.authsmtp.co.uk [62.13.136.79]) by developer.postgresql.org (Postfix) with ESMTP id 952BB2E002C for ; Tue, 27 May 2008 16:33:26 -0300 (ADT) Received: from mail-c188.authsmtp.com (mail-c188.authsmtp.com [62.13.128.25]) by punt2.authsmtp.com (8.14.2/8.13.8/Kp) with ESMTP id m4RJXO8q054731 for ; Tue, 27 May 2008 20:33:24 +0100 (BST) Received: from [192.168.0.3] (85-211-226-243.dyn.gotadsl.co.uk [85.211.226.243]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m4RJXMNm081970 for ; Tue, 27 May 2008 20:33:22 +0100 (BST) Subject: Hint Bits and Write I/O From: Simon Riggs To: pgsql-hackers Content-Type: text/plain Date: Tue, 27 May 2008 20:35:51 +0100 Message-Id: <1211916951.4489.232.camel@ebony.site> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Server-Quench: c4db79ff-2c23-11dd-aecc-001871e930f4 X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MOFUSTAAU Mk9RLVdJK3UEQkpF VCReGBUITgIzDi13 bBUsPExCYEpOVxVo UEJKQVhQFktgBAID Bx8AUBt0aQdCe2Fy YERnQXAVAUAYDy4A PBNUHWwPYmcuamAW Ug4Lc1cGdwocKAJH OVJ8SXIMNTEaNy8z FEprZ2lhYmxSeX8N TF0bDVMUXQ4hHyIn DxkEEX0QB0wZSm0S aDtO X-Authentic-SMTP: 61633235383639.cat.dmpriest.net.uk:1045/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200805/848 X-Sequence-Number: 118847 After some discussions at PGCon, I'd like to make some proposals for hint bit setting with the aim to reduce write overhead. Currently, when we see an un-hinted row we set the bit, if possible and then dirty the block. If we were to set the bit but *not* dirty the block we may be able to find a reduction in I/O. In many cases this would make no difference at all, since we often set hints on an already dirty block. In other cases, particularly random INSERTs, UPDATEs and DELETEs against large tables this would reduce I/O, though possibly increase accesses to clog. My proposal is to have this as a two-stage process. When we set the hint on a tuple in a clean buffer we mark it BM_DIRTY_HINTONLY, if not already dirty. If we set a hint on a buffer that is BM_DIRTY_HINTONLY then we mark it BM_DIRTY. The objective of this is to remove effects of single index accesses. If the bgwriter has time, it will write out BM_DIRTY_HINTONLY buffers, though on a consistently busy server this should not occur. This new behaviour should reduce the effects of random hint bit setting on tables with a low cache hit ratio. This can occur when a table is written/read fairly randomly and is much larger than shared_buffers. This won't change the behaviour of first-read-after-copy. To improve that behaviour, I suggest that we only move from BM_DIRTY_HINTONLY to BM_DIRTY when we are setting the hint for a new xid. If we are just setting the same xid over-and-over again then we should avoid setting the page dirty. So when data has been loaded via COPY, we will just check the status of the xid once, then scan the whole page using the single-item transaction cache. Let's discuss. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support