Re: Why are we waiting?
От | Tom Lane |
---|---|
Тема | Re: Why are we waiting? |
Дата | |
Msg-id | 14519.1202324154@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Why are we waiting? (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: Why are we waiting?
Re: Why are we waiting? |
Список | pgsql-hackers |
Gregory Stark <stark@enterprisedb.com> writes: > "Staale Smedseng" <Staale.Smedseng@Sun.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
В списке pgsql-hackers по дате отправления: