Skip site navigation (1) Skip section navigation (2)

Re: Hint Bits and Write I/O

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hint Bits and Write I/O
Date: 2008-05-28 10:08:12
Message-ID: 87hccispv7.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"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.

> 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. The
problem case is when we dirty the page but still have some hint bits to be set
on a subsequent iteration.

Of course that doesn't deal with the case where tuples are being touched
continuously. Perhaps the idea should be to treat the page as dirty every n
hint bit settings where n is the number of tuples on the page. or highest
number of unset hint bits seen on the page. or something like that.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's On-Demand Production Tuning

In response to

Responses

pgsql-hackers by date

Next:From: Matthew WakelingDate: 2008-05-28 10:45:14
Subject: Re: Outer joins and equivalence
Previous:From: Magnus HaganderDate: 2008-05-28 09:10:10
Subject: Re: Remove redundant extra_desc info for enum GUC variables?

pgsql-patches by date

Next:From: Simon RiggsDate: 2008-05-28 11:31:33
Subject: Re: Hint Bits and Write I/O
Previous:From: Magnus HaganderDate: 2008-05-28 09:04:14
Subject: Re: guc config_enum_entry add hidden field

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group