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 TYAPR01MB2990F199A42BCCE710E08440FE879@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: [PoC] Non-volatile WAL buffer  (Takashi Menjo <takashi.menjo@gmail.com>)
Responses Re: [PoC] Non-volatile WAL buffer
List pgsql-hackers
From: Takashi Menjo <takashi.menjo@gmail.com> 
> I made a new page at PostgreSQL Wiki to gather and summarize information and discussion about PMEM-backed WAL designs
andimplementations. Some parts of the page are TBD. I will continue to maintain the page. Requests are welcome.
 
> 
> Persistent Memory for WAL
> https://wiki.postgresql.org/wiki/Persistent_Memory_for_WAL

Thank you for putting together the information.

In "Allocates WAL buffers on shared buffers", "shared buffers" should be DRAM because shared buffers in Postgres means
thebuffer cache for database data.
 

I haven't tracked the whole thread, but could you collect information like the following?  I think such (partly basic)
informationwill be helpful to decide whether it's worth casting more efforts into complex code, or it's enough to place
WALon DAX-aware filesystems and tune the filesystem.
 

* What approaches other DBMSs take, and their performance gains (Oracle, SQL Server, HANA, Cassandra, etc.)
The same DBMS should take different approaches depending on the file type: Oracle recommends different things to data
filesand REDO logs.
 

* The storage capabilities of PMEM compared to the fast(est) alternatives such as NVMe SSD (read/write IOPS, latency,
throughput,concurrency, which may be posted on websites like Tom's Hardware or SNIA)
 

* What's the situnation like on Windows?


Regards
Takayuki Tsunakawa



pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Custom compression methods
Next
From: "Andrey V. Lepikhov"
Date:
Subject: Re: [POC] Fast COPY FROM command for the table with foreign partitions