Re: Disable WAL completely - Performance and Persistency research

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(dot)janes(at)gmail(dot)com> wrote:

> On Thu, Jul 7, 2016 at 1:01 AM, Netanel Katzburg <netanel10k(at)gmail(dot)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
>