| 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-23 18:47:10 |
| Message-ID: | CA+TgmoZTunQmdaEn1uS17H+G9uNvLQWmV4bgt0hFm9HaWNLApg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jan 19, 2018 at 9:42 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2018-01-23 18:50:59 | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |
| Previous Message | Alvaro Herrera | 2018-01-23 18:39:51 | Re: Remove utils/dsa.h from autovacuum.c |