Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Cc: Yoshimi Ichiyanagi <ichiyanagi(dot)yoshimi(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "menjo(dot)takashi(at)lab(dot)ntt(dot)co(dot)jp" <menjo(dot)takashi(at)lab(dot)ntt(dot)co(dot)jp>, "ishizaki(dot)teruaki(at)lab(dot)ntt(dot)co(dot)jp" <ishizaki(dot)teruaki(at)lab(dot)ntt(dot)co(dot)jp>
Subject: Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory
Date: 2018-01-25 14:30:45
Message-ID: CA+TgmobDO4qj2nMLdm2Dv5VRT8cVQjv7kftsS_P-kNpNw=TRug@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 24, 2018 at 10:31 PM, Tsunakawa, Takayuki
<tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:
>> This is just a guess, of course. You didn't mention what the underlying
>> storage for your test was?
>
> Uh, your guess was correct. My file system was ext3, where fsync() writes all dirty buffers in page cache.

Oh, ext3 is terrible. I don't think you can do any meaningful
benchmark results on ext3. Use ext4 or, if you prefer, xfs.

> As you said, open_datasync was 20% faster than fdatasync on RHEL7.2, on a LVM volume with ext4 (mounted with options noatime, nobarrier) on a PCIe flash memory.

So does that mean it was faster than your PMDK implementation?

> What do you think about changing the default value of wal_sync_method on Linux in PG 11? I can understand the concern that users might hit performance degredation if they are using PostgreSQL on older systems. But it's also mottainai that many users don't notice the benefits of wal_sync_method = open_datasync on new systems.

Well, some day persistent memory may be a common enough storage
technology that such a change makes sense, but these days most people
have either SSD or spinning disks, where the change would probably be
a net negative. It seems more like something we might think about
changing in PG 20 or PG 30.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2018-01-25 14:32:45 Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index
Previous Message Peter Eisentraut 2018-01-25 14:29:29 Re: [HACKERS] Support for Secure Transport SSL library on macOS as OpenSSL alternative