Re: v7.1b4 bad performance

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "Schmidt, Peter" <peter(dot)schmidt(at)prismedia(dot)com>
Cc: "'Tom Lane'" <tgl(at)sss(dot)pgh(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:31:29
Message-ID: 200102170331.WAA26980@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

[ Charset ISO-8859-1 unsupported, converting... ]
>
>
> > -----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.

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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Bruce Momjian 2001-02-17 03:43:17 Re: v7.1b4 bad performance
Previous Message Tom Lane 2001-02-17 03:13:24 Re: v7.1b4 bad performance