Disable WAL completely - Performance and Persistency research - Mailing list pgsql-hackers

From Netanel Katzburg
Subject Disable WAL completely - Performance and Persistency research
Date
Msg-id CAFN9q6RGoT3sYY=qeHA6AhV7YN5zOX2H1hvU5XY2Jrg+FefxEw@mail.gmail.com
Whole thread Raw
Responses Re: Disable WAL completely - Performance and Persistency research  (Michael Paquier <michael.paquier@gmail.com>)
Re: Disable WAL completely - Performance and Persistency research  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
Hi All,

As part of my masters at TAU, I'm currently conducting some research regarding new persistent memory technology.
I'm using PG for this research and would like to better understand some of the performance bottlenecks.
For this reason I'm trying to disable the WAL completely, using some hacks on the source code and compiling my own version.

So what I'm actually looking for, is some guidance about a simple way to:

1. Disable the WAL by not writing anything to the xlog directory. I don't care about recovery/fault tolerance or PITR/ replication etc at the moment.
I'm aware that the WAL and checkpoint are bind in many ways and are crucial for PG core features.
I tried changing the status of all tables to "unlogged" tables by changing RelationNeedsWAL MACRO, as well as "needs_wal" parameter at storage.c.
But, got no performance benefit, so I guess this was the wrong place to change.

2. Cancel the locking around WAL files  - I don't care about corrupted files at the moment, I just want to see what is the maximum performance benefit that I can get without lock contention.
 
Any guidance on how to do so would be appreciated :)
 
Kind regards,
Netanel

pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: can we optimize STACK_DEPTH_SLOP
Next
From: Michael Paquier
Date:
Subject: Re: Disable WAL completely - Performance and Persistency research