From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Reducing contention for the LockMgrLock |
Date: | 2005-12-09 14:17:55 |
Message-ID: | 10833.1134137875@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Thu, 2005-12-08 at 09:44 -0500, Tom Lane wrote:
>> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
>>> You're looking at the number of spins to acquire each lock?
>>
>> Number of semop waits.
>
> I wonder whether that is the thing to measure. That measure doesn't show
> how long each waiter waited.
True, but what I am focusing on minimizing right now is the number of
context swaps, and so number of semops seems an adequate proxy. I don't
see any way to measure wait time without adding an intolerable amount of
overhead (enough to change the behavior --- a true Heisenberg problem).
Moreover, any high-semop-rate lock is going to have very short wait
times: the time spent holding the lock has to be short by definition,
else you couldn't get to the point of having a high rate of attempts to
acquire the lock. So I don't expect that the wait-time curve would be
very interesting even if we could measure it.
>>> Manfred's earlier patch provides very clear output for observing
>>> contention, including full summaries. Could we commit that, so we can
>>> all use this for analysis? Updated with the wait info.
>>
>> What patch would that be?
>
> Sorry, thought Manfred had written the earlier patch.
I still don't know what you are referring to.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-12-09 14:43:33 | Re: Warm-cache prefetching |
Previous Message | Christopher Browne | 2005-12-09 13:47:41 | Re: Replication on the backend |