Re: Hint Bits and Write I/O - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Hint Bits and Write I/O
Date
Msg-id 1211974293.4489.417.camel@ebony.site
Whole thread Raw
In response to Re: Hint Bits and Write I/O  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
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.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: "Pavan Deolasee"
Date:
Subject: Avoiding second heap scan in VACUUM
Next
From: Dave Cramer
Date:
Subject: Re: [JDBC] How embarrassing: optimization of a one-shot query doesn't work