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

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

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "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 14:36:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:

> The default and minimum value for this parameter is 1, so very similar to
> existing behaviour. Expected settings would be 2-5, possibly as high as 20,
> though those are just educated guesses. So the maximum is set arbitrarily as
> 100.

Not a fan of arbitrary constants. ISTM this should just have a maximum of

I'm not really happy with having this parameter at all. It's not something a
DBA can understand or have any hope of setting intelligently. I assume this is
a temporary measure until we have a better understanding of what real-world
factors affect the right values for this knob?

> Temp buffers are never dirtied by hint bit setting. Most temp tables are
> written in a single command, so that re-accessing clog for temp tuples
> is seldom costly. This also changes current behaviour.

I'm not sure I agree with this logic and it doesn't seem like temporary tables
are an important enough case to start coming up with special cases which may
help or may hurt. Most people use temporary tables the way you describe but
I'm sure there's someone out there using temporary tables in a radically
different fashion.

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. What about how old the
oldest transaction is which was hinted? 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?

  Gregory Stark
  Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

In response to


pgsql-hackers by date

Next:From: Michael MeskesDate: 2008-06-27 14:41:02
Subject: Re: ecpg generated files ignorable?
Previous:From: Gregory StarkDate: 2008-06-27 14:25:47
Subject: Re: [HACKERS] Hint Bits and Write I/O

pgsql-patches by date

Next:From: Simon RiggsDate: 2008-06-27 14:53:56
Subject: Re: [HACKERS] Hint Bits and Write I/O
Previous:From: Gregory StarkDate: 2008-06-27 14:25:47
Subject: Re: [HACKERS] Hint Bits and Write I/O

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