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

Re: [HACKERS] Hint Bits and Write I/O

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>,"List pgsql-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Hint Bits and Write I/O
Date: 2008-06-27 16:04:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Gregory Stark wrote:
> I'm also a bit concerned that *how many hint bits* isn't enough information to
> determine how important it is to write out the page. 

Agreed, that doesn't seem like a very good metric to me either.

> Or how many *unhinted* xmin/xmax
> values were found? If HTSV can hint xmin for a tuple but finds xmax still in
> progress perhaps that's a good sign it's not worth dirtying the page?

I like that thought.

Overall, I feel that we should never dirty when setting a hint bit, just 
set the separate buffer flag to indicate that hint bits have been set. 
The decision to dirty and write out, or not, should be delayed until 
we're about to write/replace the buffer. That is, in bgwriter.

How about this strategy:

1. First of all, before writing a dirty buffer, scan all tuples on the 
page and set all hint bits that can be set. This will hopefully save us 
from having to dirty the page again in the future, when another tuple on 
the page is accessed. This has been proposed before, and IIRC Tom has 
argued that it's a modularity violation for bgwriter to access the 
contents of pages like that, but I'm sure we can find a way to do it safely.

2. When bgwriter encounters a page that's marked as "hint bits dirty", 
write it only if *all* hint bits on the page has been, or can be, set. 
Dirtying a page before that point doesn't seem worthwhile, as the next 
access to the tuple that doesn't have all the hint bits set will have to 
dirty the page again.

Actually, I'd like to see some benchmarks on an even simpler strategy:
just never dirty a page just because a hint bit has been set. It might 
work surprisingly well in practice: If a database is I/O bound, we don't 
care about the extra CPU work or lock congestion of checking the clog. 
If it's CPU bound, the active pages that matter are in the buffer cache, 
and so are the hint bits for those pages.

   Heikki Linnakangas

In response to

pgsql-hackers by date

Next:From: Florian PflugDate: 2008-06-27 16:06:27
Subject: Re: Planner creating ineffective plans on LEFT OUTER joins
Previous:From: Hiroshi SaitoDate: 2008-06-27 15:55:54
Subject: Re: MSVC 2003 compile error with pg8.3.3

pgsql-patches by date

Next:From: Heikki LinnakangasDate: 2008-06-27 16:36:50
Subject: Relation forks & FSM rewrite patches
Previous:From: Simon RiggsDate: 2008-06-27 15:02:18
Subject: Re: [HACKERS] Hint Bits and Write I/O

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