RE: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

From: Robert Haas [mailto:robertmhaas(at)gmail(dot)com]
> Oh, incidentally -- in our internal testing, we found that
> wal_sync_method=open_datasync was significantly faster than
> wal_sync_method=fdatasync. You might find that open_datasync isn't much
> different from pmem_drain, even though they're both faster than fdatasync.

That's interesting. How fast was open_datasync in what environment (Linux distro/kernel version, HDD or SSD etc.)?

Is it now time to change the default setting to open_datasync on Linux, at least when O_DIRECT is not used (i.e. WAL archiving or streaming replication is used)?

[Current port/linux.h]
/*
* Set the default wal_sync_method to fdatasync. With recent Linux versions,
* xlogdefs.h's normal rules will prefer open_datasync, which (a) doesn't
* perform better and (b) causes outright failures on ext4 data=journal
* filesystems, because those don't support O_DIRECT.
*/
#define PLATFORM_DEFAULT_SYNC_METHOD SYNC_METHOD_FDATASYNC

pg_test_fsync showed open_datasync is slower on my RHEL6 VM:

----------------------------------------ep
5 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 4276.373 ops/sec 234 usecs/op
fdatasync 4895.256 ops/sec 204 usecs/op
fsync 4797.094 ops/sec 208 usecs/op
fsync_writethrough n/a
open_sync 4575.661 ops/sec 219 usecs/op

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 2243.680 ops/sec 446 usecs/op
fdatasync 4347.466 ops/sec 230 usecs/op
fsync 4337.312 ops/sec 231 usecs/op
fsync_writethrough n/a
open_sync 2329.700 ops/sec 429 usecs/op
----------------------------------------ep

Regards
Takayuki Tsunakawa