Re: Potential Large Performance Gain in WAL synching

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Curtis Faith" <curtis(at)galtair(dot)com>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Pgsql-Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Potential Large Performance Gain in WAL synching
Date: 2002-10-04 21:14:56
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA4961EAF@m0114.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> > ... most file systems can't process fsync's
> > simultaneous with other writes, so those writes block because the file
> > system grabs its own internal locks.
>
> Oh? That would be a serious problem, but I've never heard that asserted
> before. Please provide some evidence.
>
> On a filesystem that does have that kind of problem, can't you avoid it
> just by using O_DSYNC on the WAL files?

To make this competitive, the WAL writes would need to be improved to
do more than one block (up to 256k or 512k per write) with one write call
(if that much is to be written for this tx to be able to commit).
This should actually not be too difficult since the WAL buffer is already
contiguous memory.

If that is done, then I bet O_DSYNC will beat any other config we currently
have.

With this, a separate disk for WAL and large transactions you shoud be able
to see your disks hit the max IO figures they are capable of :-)

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2002-10-04 21:21:49 ALTER TABLE ... ADD COLUMN
Previous Message Tom Lane 2002-10-04 20:45:22 Re: Potential Large Performance Gain in WAL synching