To: Robert Lor <Robert.Lor@Sun.COM>
cc: Jan de Visser <jdevisser@digitalfairway.com>,
	Greg Smith <gsmith@gregsmith.com>,
	Alvaro Herrera <alvherre@commandprompt.com>,
	pgsql-performance@postgresql.org
Subject: Re: I/O on select count(*) 
In-reply-to: <482C6AE4.8020607@sun.com> 
References: <920841.71690.qm@web44808.mail.sp1.yahoo.com>
	<482B1D5F.EE98.0025.0@wicourts.gov>
	<Pine.GSO.4.64.0805142133250.27290@westnet.com>
	<20080515020553.GN9838@alvh.no-ip.org>
	<Pine.GSO.4.64.0805142211300.5617@westnet.com>
	<1159c1e90805141938j5f85b490rb5c1cfdf9e428bce@mail.gmail.com>
	<28324.1210834939@sss.pgh.pa.us> <482C6AE4.8020607@sun.com>
Comments: In-reply-to Robert Lor <Robert.Lor@Sun.COM>
	message dated "Thu, 15 May 2008 11:55:00 -0500"
Date: Thu, 15 May 2008 13:42:09 -0400
Message-ID: <8796.1210873329@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Robert Lor <Robert.Lor@Sun.COM> writes:
> Tom Lane wrote:
>> It's certainly true that hint-bit updates cost something, but
>> quantifying how much isn't easy. 

> Maybe we can instrument the code with DTrace probes to quantify the 
> actual costs.

Hmm, the problem would be trying to figure out what percentage of writes
could be blamed solely on hint-bit updates and not any other change to
the page.  I don't think that the bufmgr currently keeps enough state to
know that, but you could probably modify it easily enough, since callers
distinguish MarkBufferDirty from SetBufferCommitInfoNeedsSave.  Define
another flag bit that's set only by the first, and test it during
write-out.

			regards, tom lane