On Tue, Jan 18, 2011 at 3:00 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 18.01.2011 21:16, Robert Haas wrote:
>>
>> On Tue, Jan 18, 2011 at 1:32 PM, Tom Lane<tgl@sss.pgh.pa.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