Your patch is very helpful, I'm still checking it on different file-systems. I really liked the idea of using only the edge checkpoints. Thanks.
On Mon, Jul 11, 2016 at 9:26 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Thu, Jul 7, 2016 at 1:01 AM, Netanel Katzburg <netanel...@gmail.com> > wrote: > > 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 :) > > I have a very old patch which introduces a config variable (JJNOWAL) > that skips all WAL, except for the WAL of certain checkpoints (which > are needed for initdb and to restart the server after a clean > shutdown). > > I have rebased it up to HEAD. It seems to work, but I haven't tested > thoroughly that it still does the correct thing in every corner case. > (a lot of changes have been made to xlog code since last time I used > this.) > > Obviously if the server goes down uncleanly while this setting is > active, it will not be usable anymore. > > Cheers, > > Jeff >
