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>, "yoshmiyana(at)gmail(dot)com" <yoshmiyana(at)gmail(dot)com>
Subject: Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory
Date: 2018-01-24 12:58:28
Message-ID: CA+Tgmobz4kc5f5iv88NqGHG_EYPDJjKtyKqEePhWyrP+f+57Kg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 23, 2018 at 8:07 PM, Tsunakawa, Takayuki
<tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:
> From: Robert Haas [mailto:robertmhaas(at)gmail(dot)com]
>> 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.
>
> That's interesting. How fast was open_datasync in what environment (Linux distro/kernel version, HDD or SSD etc.)?
>
> Is it now time to change the default setting to open_datasync on Linux, at least when O_DIRECT is not used (i.e. WAL archiving or streaming replication is used)?

I think open_datasync will be worse on systems where fsync() is
expensive -- it forces the data out to disk immediately, even if the
data doesn't need to be flushed immediately. That's bad, because we
wait immediately when we could have deferred the wait until later and
maybe gotten the WAL writer to do the work in the background. But it
might be better on systems where fsync() is basically free, because
there you might as well just get it out of the way immediately and not
leave something left to be done later.

This is just a guess, of course. You didn't mention what the
underlying storage for your test was?

--
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 Feike Steenbergen 2018-01-24 13:15:31 Re: Fix permissions check on pg_stat_get_wal_senders
Previous Message Petr Jelinek 2018-01-24 12:53:50 Re: [PATCH] Logical decoding of TRUNCATE