On Fri, 2008-01-25 at 19:02 -0500, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > Patch to reduce the contention on SInvalLock, as discussed here: > > http://archives.postgresql.org/pgsql-hackers/2007-09/msg00501.php > > and > > http://archives.postgresql.org/pgsql-performance/2008-01/msg00023.php > > > For discussion. > > This seems large, complex, and untested (I note in particular a > guaranteed-to-fail Assert).
Yes, its for discussion. How would you describe such a patch in the future? I want to be able to differentiate patch status. There's no point polishing it before the discussion. > I'm also wondering if it will help much, > since unless the system is already in trouble, the normal case will be > that all backends have absorbed all messages and so they'll all see > stateP->nextMsgNum == segP->minMsgNum when they first respond to a > signal. Agreed, that's why its not the only condition. In the patch, the message queue is normally cleaned when an insert gets past 50% of queue length, then again at 56%, 62% and 68%. If that doesn't help then we hit the PM signal at 70% as before. We don't attempt to clean the queue after every round of messages by each backend, which causes huge contention as we know. We only clean the queue if a long run of messages is read by the oldest message reader, so when stateP->nextMsgNum == segP->minMsgNum && number of messages read > 25% of queue. So that is only performed by a backend waking up to find it is behind, such as would happen if a PM signal had been issued. > Do you have any evidence for performance improvement? ISTM that it would only be worth testing when we had a rough agreement that we had found a reasonable approach. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
