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@xxxxxxxxxxxxxxx www.2ndQuadrant.us -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
