Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory
Date
Msg-id CA+TgmobDO4qj2nMLdm2Dv5VRT8cVQjv7kftsS_P-kNpNw=TRug@mail.gmail.com
Whole thread Raw
In response to RE: [HACKERS][PATCH] Applying PMDK to WAL operations for persistentmemory  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses RE: [HACKERS][PATCH] Applying PMDK to WAL operations for persistentmemory
Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistentmemory
Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory
List pgsql-hackers
On Wed, Jan 24, 2018 at 10:31 PM, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.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
concernthat users might hit performance degredation if they are using PostgreSQL on older systems.  But it's also
mottainaithat 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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Support for Secure Transport SSL library on macOS asOpenSSL alternative
Next
From: Alexander Korotkov
Date:
Subject: Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index