Re: limiting hint bit I/O

2011/2/5 Robert Haas <robertmhaas(at)gmail(dot)com>:
> 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).

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