Re: pgsql-server/src backend/storage/buffer/bufmgr ...

Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> Now doing fsync() or fdatasync() of possibly dozens of files in a row,
> forcing the kernel to do one scattered file after another, letting the
> disk heads dance like step-chicken on a hot tin ... that will be an
> improvement, oh boy.

I'm not convinced it would be so bad. Normally you'd only be issuing
those operations at checkpoint time, and if the bgwriter has been doing
its job and pushing out dirty pages to the kernel, the kernel should
have been busily writing pages all along since the last checkpoint.
In theory the fsync would not force all that many new writes (certainly
lots less than a once-per-checkpoint sync does). Also keep in mind that
fsync is not defined as "write this page NOW". It is defined as "let me
know when you've written it". The kernel still has flexibility in
scheduling its writes, and may choose to write other pages along the
way.

Perhaps more to the point: all this is predicated on an assumption no
longer particularly valid, which is that the kernel's ideas about disk
write scheduling matter at all. A decent SCSI disk drive will pre-empt
the kernel's ideas anyway by absorbing as many pending writes as it can
and then doing its own write scheduling. fsync won't affect the drive's
choices in the least, only allow us to find out when the drive is done.

regards, tom lane