Re: limiting hint bit I/O

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> I think you may be confused about what the patch does - currently,
>>> pages with hint bit changes are considered dirty, period.
>>> Therefore, they are written whenever any other dirty page would be
>>> written: by the background writer cleaning scan, at checkpoints,
>>> and when a backend must write a dirty buffer before reallocating it
>>> to hold a different page. The patch keeps the first of these and
>>> changes the second two

While I was trying to performance-test the texteq patch, it occurred to
me that this proposed hint-bit change has got a serious drawback. To
wit, that it will totally destroy reproducibility of any performance
test that involves table scans. Right now, you know that you can take
hint bits out of the equation by doing a vacuum analyze and checkpoint;
after that, all hint bits in the table are known to be set and written
to disk. Then you can get on with comparing the effects of some patch
or other. With the proposed patch, it will never be clear whether
all the hint bits are set, because the patch specifically removes the
deterministic ways to get a hint bit written out. So you'll never be
very sure whether a performance difference you think you see is real,
or whether one case or the other got affected by extra clog lookups.
It's hard enough already to be sure about performance changes on the
order of 1%, but this will make it impossible.

regards, tom lane