Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-admin by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group