| From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Curtis Faith" <curtis(at)galtair(dot)com>, "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 23:47:12 |
| Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4961EB1@m0114.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Hmmm ... if you were willing to dedicate a half meg or meg of shared
> memory for WAL buffers, that's doable.
Yup, configuring Informix to three 2 Mb buffers (LOGBUF 2048) here.
> However, this would only be a win if you had few and large transactions.
> Any COMMIT will force a write of whatever we have so far, so the idea of
> writing hundreds of K per WAL write can only work if it's hundreds of K
> between commit records. Is that a common scenario? I doubt it.
It should help most for data loading, or mass updating, yes.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Copeland | 2002-10-05 00:17:56 | Re: Potential Large Performance Gain in WAL synching |
| Previous Message | Michael Paesold | 2002-10-04 23:42:08 | Re: Improving backend startup interlock |