On Fri, Jan 19, 2018 at 4:56 AM, Yoshimi Ichiyanagi <ichiyanagi.yosh...@lab.ntt.co.jp> wrote: >>Was the only non-default configuration setting wal_sync_method? i.e. >>synchronous_commit=on? No change to max_wal_size? > No, I used the following parameter in postgresql.conf to prevent > checkpoints from occurring while running the tests.
I think that you really need to include the checkpoints in the tests. I would suggest setting max_wal_size and/or checkpoint_timeout so that you reliably complete 2 checkpoints in a 30-minute test, and then do a comparison on that basis. > Do you know any good WAL I/O intensive benchmarks? DBT2? pgbench is quite a WAL-intensive benchmark; it is much more write-heavy than what most systems experience in real life, at least in my experience. Your comparison of DAX FS to DAX FS + PMDK is very interesting, but in real life the bandwidth of DAX FS is already so high -- and the latency so low -- that I think most real-world workloads won't gain very much. At least, that is my impression based on internal testing EnterpriseDB did a few months back. (Thanks to Mithun and Kuntal for that work.) That's not necessarily an argument against this patch, which by the way I have not reviewed. Even a 5% speedup on this kind of workload is potentially worthwhile; everyone likes it when things go faster. I'm just not convinced you can get very much more than that on a realistic workload. Of course, I might be wrong. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company