2011/2/5 Robert Haas <robertmh...@gmail.com>: > 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).
mmhh, sure. > >>> 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.) > just reading the patch... I understand the idea of the 5% flush. *maybe* it make sense to use effective_io_concurrency GUC here to improve the ratio, but it might be perceived as a bad usage .. currently effective_io_concurrency is for planning purpose. -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
