Re: limiting hint bit I/O

On 18.01.2011 21:16, Robert Haas wrote:
> On Tue, Jan 18, 2011 at 1:32 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
>
> True. You could perhaps fix that by adding a GUC, but that feels
> awfully like making it the user's problem to fix our broken
> implementation. Maybe we could live with it if the GUC were only
> something developers ever needed to use, but I expect different people
> would have different ideas about the correct setting in production.

VACUUM (SET HINT BITS) <table>

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com