[ Charset ISO-8859-1 unsupported, converting... ]
>
>
> > -----Original Message-----
> > From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> > I got roughly twice the tps reading (pgbench -t 1000, with
> > -F) at -B 1024.
> >
>
> I tried -B 1024 and got roughly the same results (~50 tps). However, when I
> change WAL option commit_delay from the default of 5 to 0, I get ~200 tps
> (which is double what I get with 7.03). I'm not sure I want to do this, do
> I?
>
> Peter
>
> The <varname>COMMIT_DELAY</varname> parameter defines for how long
> the backend will be forced to sleep after writing a commit record
> to the log with <function>LogInsert</function> call but before
> performing a <function>LogFlush</function>. This delay allows other
> backends to add their commit records to the log so as to have all
> of them flushed with a single log sync. Unfortunately, this
> mechanism is not fully implemented at release 7.1, so there is at
> present no point in changing this parameter from its default value
> of 5 microseconds.
Woh, I could swear we were going for zero delay for this parameter for
7.1. The idea was that we should look to see if other backends are
about to commit before doing the delay. If we don't have time to code
that, the delay itself it just a throttle on performance. I recommend
setting the default to zero, which is what I thought Vadim agreed to.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026