From: Robert Haas [mailto:robertmhaas@gmail.com]
> If I understand correctly, those results are all just pg_test_fsync results.
> That's not reflective of what will happen when the database is actually
> running. When you use open_sync or open_datasync, you force WAL write and
> WAL flush to happen simultaneously, instead of letting the WAL flush be
> delayed.
Yes, that's pg_test_fsync output. Isn't pg_test_fsync the tool to determine the value for wal_sync_method? Is this
manualmisleading?
https://www.postgresql.org/docs/devel/static/pgtestfsync.html
--------------------------------------------------
pg_test_fsync - determine fastest wal_sync_method for PostgreSQL
pg_test_fsync is intended to give you a reasonable idea of what the fastest wal_sync_method is on your specific system,
aswell as supplying diagnostic information in the event of an identified I/O problem.
--------------------------------------------------
Anyway, I'll use pgbench, and submit a patch if open_datasync is better than fdatasync. I guess the current tweak of
makingfdatasync the default is a holdover from the era before ext4 and XFS became prevalent.
> I don't have the results handy at the moment. We found it to be faster
> on a database benchmark where the WAL was stored on an NVRAM device.
Oh, NVRAM. Interesting. Then I'll try open_datasync/fdatasync comparison on HDD and SSD/PCie flash with pgbench.
Regards
Takayuki Tsunakawa