RE: v7.1b4 bad performance

From: "Schmidt, Peter" <peter(dot)schmidt(at)prismedia(dot)com>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Schmidt, Peter" <peter(dot)schmidt(at)prismedia(dot)com>
Cc: "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "'Michael Ansley'" <Michael(dot)Ansley(at)intec-telecom-systems(dot)com>, "'pgsql-admin(at)postgresql(dot)org'" <pgsql-admin(at)postgresql(dot)org>
Subject: RE: v7.1b4 bad performance
Date: 2001-02-17 03:04:27
Message-ID: F1DC8388AD52D411B83B00D0B774D6EB1928E3@winmail.prismedia.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)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.

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2001-02-17 03:13:24 Re: v7.1b4 bad performance
Previous Message Tom Lane 2001-02-17 01:49:36 Re: v7.1b4 bad performance