RE: [PoC] Non-volatile WAL buffer - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: [PoC] Non-volatile WAL buffer
Date
Msg-id TYAPR01MB2990B44B0817FD881CD94177FEFA0@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: [PoC] Non-volatile WAL buffer  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: [PoC] Non-volatile WAL buffer  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
> It's interesting that they only place the tail of the log on PMEM, i.e.
> the PMEM buffer has limited size, and the rest of the log is not on
> PMEM. It's a bit as if we inserted a PMEM buffer between our wal buffers
> and the WAL segments, and kept the WAL segments on regular storage. That
> could work, but I'd bet they did that because at that time the NV
> devices were much smaller, and placing the whole log on PMEM was not
> quite possible. So it might be unnecessarily complicated, considering
> the PMEM device capacity is much higher now.
> 
> So I'd suggest we simply try this:
> 
>     clients -> buffers (DRAM) -> wal segments (PMEM)
> 
> I plan to do some hacking and maybe hack together some simple tools to
> benchmarks various approaches.

I'm in favor of your approach.  Yes, Intel PMEM were available in 128/256/512 GB when I checked last year.  That's more
thanenough to place all WAL segments, so a small PMEM wal buffer is not necessary.  I'm excited to see Postgres gain
morepower.
 


Regards
Takayuki Tsunakawa


pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: Re: About adding a new filed to a struct in primnodes.h
Next
From: "Bossart, Nathan"
Date:
Subject: Re: A few new options for CHECKPOINT