From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Dmitry Morozovsky <marck(at)rinet(dot)ru> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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:59:40 |
Message-ID: | 200102181959.OAA02190@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers |
> 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.
According to the BSD4.4 book by Karels/McKusick, even though computers
are faster now, increasing the Hz doesn't seem to improve performance.
This is probably because of cache misses from context switches.
--
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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Graichen | 2001-02-18 20:31:03 | Re: postgres & smp |
Previous Message | Dmitry Morozovsky | 2001-02-18 19:36:03 | Re: v7.1b4 bad performance |
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Myers | 2001-02-18 20:08:02 | Re: Re: WAL and commit_delay |
Previous Message | Dmitry Morozovsky | 2001-02-18 19:36:03 | Re: v7.1b4 bad performance |