On Tue, Jan 23, 2018 at 8:07 PM, Tsunakawa, Takayuki <tsunakawa.ta...@jp.fujitsu.com> wrote: > From: Robert Haas [mailto:robertmh...@gmail.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)?
I think open_datasync will be worse on systems where fsync() is expensive -- it forces the data out to disk immediately, even if the data doesn't need to be flushed immediately. That's bad, because we wait immediately when we could have deferred the wait until later and maybe gotten the WAL writer to do the work in the background. But it might be better on systems where fsync() is basically free, because there you might as well just get it out of the way immediately and not leave something left to be done later. This is just a guess, of course. You didn't mention what the underlying storage for your test was? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
