On Thu, 2008-02-14 at 16:50 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> 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
