On Fri, 2008-01-25 at 19:02 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> 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
