On Sat, Feb 5, 2011 at 3:07 PM, Cédric Villemain <cedric.villemain.deb...@gmail.com> wrote: >> So I think this probably needs more testing >> before we decide whether or not it's a good idea. > > I *may* have an opportunity to test that in a real world application > where this hint bit was an issue.
That would be great. But note that you'll also need to compare it against an unpatched 9.1devel; otherwise we won't be able to tell whether it's this helping, or some other 9.1 patch (particularly, the fsync compaction patch). >> I did that. Also, per my previous >> musings, I've adjusted this version so that vacuum behaves differently >> when dirtying pages rather than when flushing them. In versions 1 and >> 2, vacuum would always write pages that were dirty-only-for-hint-bits >> when allocating a new buffer; in this version the buffer allocation >> logic is the same for vacuum, but it marks pages dirty even when only >> hint bits have changed. The result is that VACUUM followed by >> CHECKPOINT is enough to make sure all hint bits are set on disk, just >> as is the case today. > > for now it looks better to reduce this impact, yes.. > Keeping the logic from v1 or v2 imply vacuum freeze to 'fix' the hint > bit, right ? In v1, you'd need to actually dirty the pages, so yeah, VACUUM (FREEZE) would be pretty much the only way. In v2, regular VACUUM would mostly work, except it might miss a smattering of hint bits at the very end of its scan. In this version (v3), that's been fixed as well and now just plain VACUUM should be entirely sufficient. (The last few pages examined might not get evicted to disk right away, just as in the current code, but they're guaranteed to be written eventually unless a system crash intervenes, again just as in the current code.) -- 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
