Re: limiting hint bit I/O

On Sat, Feb 5, 2011 at 3:07 PM, Cédric Villemain
<cedric(dot)villemain(dot)debian(at)gmail(dot)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