RE: [PoC] Non-volatile WAL buffer
| От | tsunakawa.takay@fujitsu.com |
|---|---|
| Тема | RE: [PoC] Non-volatile WAL buffer |
| Дата | |
| Msg-id | TYAPR01MB2990B44B0817FD881CD94177FEFA0@TYAPR01MB2990.jpnprd01.prod.outlook.com обсуждение исходный текст |
| Ответ на | Re: [PoC] Non-volatile WAL buffer (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
| Ответы |
Re: [PoC] Non-volatile WAL buffer
|
| Список | 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 по дате отправления: