Subject: Re: Hint Bits and Write I/O
From: Simon Riggs <simon@2ndquadrant.com>
To: Gregory Stark <stark@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
In-Reply-To: <87hccispv7.fsf@oxford.xeocode.com>
References: <1211916951.4489.232.camel@ebony.site>
	<15901.1211931165@sss.pgh.pa.us>  <87hccispv7.fsf@oxford.xeocode.com>
Content-Type: text/plain
Date: Wed, 28 May 2008 12:31:33 +0100
Message-Id: <1211974293.4489.417.camel@ebony.site>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


On Wed, 2008-05-28 at 06:08 -0400, Gregory Stark wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
> 
> > (Although that argument might not hold water for a bulk seqscan: you'll
> > have hinted all the tuples and then very possibly throw the page away
> > immediately.  
> 
> That seems like precisely the case where we don't want to dirty the buffer.

(1)

> > So counting the hints and eventually deciding we did
> > enough to justify dirtying the page might be worth doing.)
> 
> What if we counted how many hint bits were *not* set? I feel like the goal
> should be to dirty the buffer precisely once when all the bits can be set. 

(2)

Agreed. I think the difficulty is that (1) and (2) are contradictory
goals, and since those conditions frequently occur together, cause
conflict. 

When we fully scan a buffer this will result in 1 or more actual clog
lookups, L.  L is often less than the number of tuples on the page
because of the single-item xid cache. If L = 1 then there is a high
probability that when we do a seq scan the clog blocks will be cached
also, so although we do a 1 clog lookup per table block we would seldom
do clog I/O during a SeqScan. So what I tried to say in a previous post
was that if L > 1 then we should dirty the buffer because the
single-item cache becomes less-effective and we may need to access other
clog blocks, that may result in clog I/O.

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support