RE: v7.1b4 bad performance - Mailing list pgsql-admin

From Schmidt, Peter
Subject RE: v7.1b4 bad performance
Date
Msg-id F1DC8388AD52D411B83B00D0B774D6EB1928E3@winmail.prismedia.com
Whole thread Raw
In response to v7.1b4 bad performance  ("Schmidt, Peter" <peter.schmidt@prismedia.com>)
Responses Re: v7.1b4 bad performance  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: v7.1b4 bad performance  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: v7.1b4 bad performance  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-admin


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

pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: v7.1b4 bad performance
Next
From: Tom Lane
Date:
Subject: Re: v7.1b4 bad performance