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