Re: Slightly reduce BufMgrLock contention - Mailing list pgsql-patches

From Tom Lane
Subject Re: Slightly reduce BufMgrLock contention
Date
Msg-id 219.1030716754@sss.pgh.pa.us
Whole thread Raw
In response to Slightly reduce BufMgrLock contention  (Manfred Koizar <mkoi-pg@aon.at>)
Responses Re: Slightly reduce BufMgrLock contention  (Manfred Koizar <mkoi-pg@aon.at>)
List pgsql-patches
Manfred Koizar <mkoi-pg@aon.at> writes:
> This patch prevents btbulkdelete() from calling WriteNoReleaseBuffer()
> several times for the same buffer.  Thus it saves a few
> LWLockAquire(BufMgrLock, LW_EXCLUSIVE) and LWLockRelease(BufMgrLock)
> calls.

I don't like this patch, because it embeds into the caller the notion
that it's okay to keep changing the page *after* calling WriteBuffer.
It would stop working if we ever re-implemented the buffer manager in
a way that caused writes to appear synchronous.  I'm not sure that's
likely, but for the amount of gain here I do not think that introducing
extra coupling between btbulkdelete and bufmgr internal details is a
good idea.

What would make more sense is to tweak write_buffer to behave the way
SetBufferCommitInfoNeedsSave does, thus buying a similar speedup
globally instead of only for this one caller.

(In fact, since SetBufferCommitInfoNeedsSave is not really different
anymore from WriteNoReleaseBuffer, you could then just reimplement it as
write_buffer(buf, false).  I don't want to eliminate the routine,
because I think it's good for callers to make the distinction between
data writes and commit-bit updates, but there's no reason for bufmgr to
contain duplicate code.)

            regards, tom lane

pgsql-patches by date:

Previous
From: "Karim Mribti"
Date:
Subject: Re: PostgreSQL spanish translation.
Next
From: Bruce Momjian
Date:
Subject: Re: fix for palloc() of user-supplied length