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
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 |