| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Hannu Krosing <hannu(at)tm(dot)ee> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, jwbaker(at)acm(dot)org |
| Subject: | Re: LWLock contention: I think I understand the problem |
| Date: | 2002-01-03 23:39:59 |
| Message-ID: | 1114.1010101199@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-odbc |
Hannu Krosing <hannu(at)tm(dot)ee> writes:
> Tom Lane wrote:
>> Unfortunately, at low scaling factors pgbench is guaranteed to look
>> horrible because of contention for the "branches" rows.
>>
> Not really! See graph in my previous post - the database size affects
> performance much more !
But the way that pgbench is currently set up, you can't really tell the
difference between database size effects and contention effects, because
you can't vary one while holding the other constant.
I based my comments on having done profiles that show most of the CPU
time going into attempts to acquire row locks for updates and/or
checking of dead tuples in _bt_check_unique. So at least in the
conditions I was using (single CPU) I think those are the bottlenecks.
I don't have any profiles for SMP machines, yet.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Brent Verner | 2002-01-04 00:50:23 | Re: More problem with scripts |
| Previous Message | Thomas Lockhart | 2002-01-03 23:03:20 | Re: More problem with scripts |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-01-04 01:02:54 | Re: LWLock contention: I think I understand the problem |
| Previous Message | Hannu Krosing | 2002-01-03 19:55:10 | Re: LWLock contention: I think I understand the problem |