| From: | "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| Cc: | "Mark Wong" <markw(at)osdl(dot)org>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: XLOG_BLCKSZ vs. wal_buffers table |
| Date: | 2006-05-03 07:54:39 |
| Message-ID: | E1539E0ED7043848906A8FF995BDA579FC3A0C@m0143.s-mxs.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > > I'm planning on continuing to increase XLOG_BLCKSZ and wal_buffers
to
> > > determine when the throughput starts to level out or drop
> >
> > I think for an even better comparison you should scale wal_buffers
> > down with increasing XLOG_BLCKSZ, so that the xlog buffer has a
fixed
> > size in kb.
> >
> > Reasonable wal_buffers imho amount to at least 256kb, better yet 512
or 1 Mb,
> > with sufficiently large transactions (and to try to factor out the
difference
> > between blocksizes).
>
> AFAIK all the transactions in DBT2 are pretty small. I think all DML
is
> single-row in fact, so I'm not sure that having wal_buffers much
larger
> than the number of connections would help much.
Well, but those updates wander around the whole table/index, so you will
have a lot of
before images to write. So I take back the "sufficiently large
transactions" part
of my comment. You want more wal_buffers in all higher load scenarios.
(one test had 8 buffers of 2k each, this is not enough in any high load
scenario)
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Staudinger | 2006-05-03 07:57:50 | [SoC] Relation between project "XML improvements" and "pgxml" |
| Previous Message | Tom Lane | 2006-05-03 03:06:59 | Re: sblock state on FreeBSD 6.1 |