On Thu, 2008-02-14 at 16:50 -0500, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > On Thu, 2008-02-14 at 13:52 -0500, Tom Lane wrote: > >> [ still staring at the code ... ] Something that might be interesting > >> though is to try to move some of the buffer control logic overhead out > >> of WALInsertLock's domain and into WALWriteLock's domain. > > > I like this one because its another example that contention is not > > static, seems like its more often cyclical. The WALInsertLock is held > > longer than normal when we cross page boundaries, creating a pulsing > > effect thru the lock queue. > > Yeah, significantly longer than normal if you assume the normal case is > to write a WAL record that's much less than a full page. But has anyone > seen direct evidence that that's an important effect? I was just > proposing this on speculation --- if there's already evidence that that > behavior is a problem, it'd be interesting to see it.
A tracepoint in AdvanceXLInsertBuffer() would help there. I would expect lock time to vary with number of cache lines touched (approximated by record size) as well as whether the record crossed a page boundary. Very large WAL records are more likely to cross boundaries, so the effect will show itself most when we write small WAL records. > BTW, we'd probably need to do something like this even if we then go > forward with your original idea. If we're going to allow multiple > backends to be inserting WAL records into the-same-or-different WAL > buffers concurrently, we can't have that same code responsible for > initializing empty buffers. You've sold me already! I will return to the other part of the idea, but just too busy now to think and reply in full. I agree with the issues you raised earlier. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match