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

Re: v7.1b4 bad performance

From: Dmitry Morozovsky <marck(at)rinet(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Schmidt, Peter" <peter(dot)schmidt(at)prismedia(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-admin(at)postgresql(dot)org
Subject: Re: v7.1b4 bad performance
Date: 2001-02-18 19:36:03
Message-ID: Pine.BSF.4.21.0102182231580.16523-100000@woozle.rinet.ru (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-hackers
On Sat, 17 Feb 2001, Tom Lane wrote:

[skip]

TL> Platform: HPUX 10.20 on HPPA C180, fast wide SCSI discs, 7200rpm (I think).
TL> Minimum select(2) delay is 10 msec on this platform.

[skip]

TL> I vote for commit_delay = 0, unless someone can show cases where
TL> positive delay is significantly better than zero delay.

BTW, for modern versions of FreeBSD kernels, there is HZ kernel option
which describes maximum timeslice granularity (actually, HZ value is
number of timeslice periods per second, with default of 100 = 10 ms). On
modern CPUs HZ may be increased to at least 1000, and sometimes even to
5000 (unfortunately, I haven't test platform by hand).

So, maybe you can test select granularity at ./configure phase and then
define default commit_delay accordingly.

Your thoughts?

Sincerely,
D.Marck                                   [DM5020, DM268-RIPE, DM3-RIPN]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck(at)rinet(dot)ru ***
------------------------------------------------------------------------


In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-02-18 19:59:40
Subject: Re: v7.1b4 bad performance
Previous:From: The Hermit HackerDate: 2001-02-18 19:00:51
Subject: Re: beta5 ...

pgsql-admin by date

Next:From: Bruce MomjianDate: 2001-02-18 19:59:40
Subject: Re: v7.1b4 bad performance
Previous:From: Tom LaneDate: 2001-02-18 16:30:08
Subject: Re: postgres & smp

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