Manfred Spraul <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It could be that I'm all wet and there is no relationship between the
>> cache line thrashing and the seemingly excessive BufMgrLock contention.
>>
> Is it important? The fix is identical in both cases: per-bucket locks
> for the hash table and a buffer aging strategy that doesn't need one
> global lock that must be acquired for every lookup.
Reducing BufMgrLock contention is a good idea, but it's not really my
idea of a fix for this issue. In the absence of a full understanding,
we may be fixing the wrong thing. It's worth remembering that when we
first hit this issue, I made some simple changes that approximately
halved the number of BufMgrLock acquisitions by joining ReleaseBuffer
and ReadBuffer calls into ReleaseAndReadBuffer in all the places in the
test case's loop. This made essentially no change in the CS storm
behavior :-(. So I do not know how much contention we have to get rid
of to get the problem to go away, or even whether this is the right path
to take.
(I am unconvinced that either of those specific suggestions is The Right
Way to break up the bufmgrlock, either, but that's a different thread.)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
