Andres Freund wrote:
> An fsync() equals a barrier so it has the effect of stopping
> reordering around it - especially on systems with larger multi-disk
> arrays thats pretty expensive.
> You can achieve surprising speedups, at least in my experience, by
> forcing the kernel to start writing out pages *without enforcing
> barriers* first and then later enforce a barrier to be sure its
> actually written out.
Standard practice on high performance systems with good filesystems and
a battery-backed controller is to turn off barriers anyway. That's one
of the first things to tune on XFS for example, when you have a reliable
controller. I don't have enough data on ext4 to comment on tuning for
it yet.
The sole purpose for the whole Linux write barrier implementation in my
world is to flush the drive's cache, when the database does writes onto
cheap SATA drives that will otherwise cache dangerously. Barriers don't
have any place on a serious system that I can see. The battery-backed
RAID controller you have to use to make fsync calls fast anyway can do
some simple write reordering, but the operating system doesn't ever have
enough visibility into what it's doing to make intelligent decisions
about that anyway.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
