From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Yoshimi Ichiyanagi <ichiyanagi(dot)yoshimi(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, menjo(dot)takashi(at)lab(dot)ntt(dot)co(dot)jp, ishizaki(dot)teruaki(at)lab(dot)ntt(dot)co(dot)jp, yoshmiyana(at)gmail(dot)com |
Subject: | Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory |
Date: | 2018-01-19 14:42:25 |
Message-ID: | CA+TgmoZygQO3EC4mMdf-b=UuY3HZz6+-Y2w5_s9bLtH4NPw6Bg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 19, 2018 at 4:56 AM, Yoshimi Ichiyanagi
<ichiyanagi(dot)yoshimi(at)lab(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-01-19 14:45:41 | Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall |
Previous Message | Simon Riggs | 2018-01-19 14:34:17 | Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions |