Re: Why are we waiting?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Staale Smedseng" <Staale(dot)Smedseng(at)Sun(dot)COM>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why are we waiting?
Date: 2008-02-06 18:55:54
Message-ID: 14519.1202324154@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Staale Smedseng" <Staale(dot)Smedseng(at)Sun(dot)COM> writes:
>> Also, an interesting observation is that the hot locks seem to have
>> changed from v8.2 to v8.3, making the ProcArrayLock more contended. See
>> the following outputs:
>>
>> PostgreSQL 8.2 (32-bit):
>> ...
>> PostgreSQL 8.3 (64-bit):
>> ...

> I'm not sure 32-bit and 64-bit cases are going to be directly comparable. We
> could have a problem with cache line aliasing on only one or the other for
> example.

Yeah, I find these numbers highly dubious. AFAIR we didn't do anything
that would have reduced CLogControlLock contention, and we definitely
did work to reduce ProcArrayLock contention, so the claimed results seem
directly opposite to expectation. I am wondering if the waits are being
attributed to the right locks --- I remember such an error in a previous
set of dtrace results, and some of the other details such as claiming
shared lock delays but no exclusive lock delays for FirstLockMgrLock
seem less than credible as well.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2008-02-06 18:56:41 Re: crash / data recovery issues
Previous Message Alvaro Herrera 2008-02-06 18:52:16 Re: PostgreSQL 8.4 development plan