Re: WAL write of full pages

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marty Scholes <marty(at)outputservices(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WAL write of full pages
Date: 2004-03-15 21:25:36
Message-ID: 7740.1079385936@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marty Scholes <marty(at)outputservices(dot)com> writes:
> I suspect (but cannot prove) that performance would jump for systems
> like ours if WAL was done away with entirely and the individual data
> files were synchronized on commit.

I rather doubt this, since we used to do things that way and we saw an
across-the-board performance improvement when we got rid of it in favor
of WAL.

> Is there a simple way to turn off WAL in the config files so that I may
> do some benchmarking?

No, there's no way to turn it off at all. You can disable fsync'ing it,
but that's hardly representative of what would happen if the data writes
had to be fsync'd instead.

Your analysis is missing an important point, which is what happens when
multiple transactions successively modify the same page. With a
sync-the-data-files approach, we'd have to write the data page again for
each commit. With WAL, the data page will likely not get written at all
(until a checkpoint happens). Instead there will be per-transaction
writes to the WAL, but the data volume will be less since WAL records
are generally tuple-sized not page-sized. There's probably no win for
large transactions that touch most of the tuples on a given data page,
but for small transactions it's a win.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Sullivan 2004-03-15 21:34:42 Re: Log rotation
Previous Message Andrew Dunstan 2004-03-15 21:24:31 Re: listening addresses