Re: Hint Bits and Write I/O

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hint Bits and Write I/O
Date: 2008-05-28 11:31:33
Message-ID: 1211974293.4489.417.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


On Wed, 2008-05-28 at 06:08 -0400, Gregory Stark wrote:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jorgen Austvik - Sun Norway 2008-05-28 12:08:14 pg_regress: referencing shared objects from tests
Previous Message Pavan Deolasee 2008-05-28 11:26:50 Avoiding second heap scan in VACUUM

Browse pgsql-patches by date

  From Date Subject
Next Message Zdenek Kotala 2008-05-28 13:07:09 pg_lzcompress patch for 8.3, 8.2 branch
Previous Message Gregory Stark 2008-05-28 10:08:12 Re: Hint Bits and Write I/O