Re: limiting hint bit I/O

On Tue, Jan 18, 2011 at 3:00 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> 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>

Something along those lines could work too, but I don't see much
problem with making VACUUM doing it unconditionally.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company