On Tue, Jan 18, 2011 at 3:00 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 18.01.2011 21:16, Robert Haas wrote: >> >> On Tue, Jan 18, 2011 at 1:32 PM, Tom Lane<t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers