From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Slightly reduce BufMgrLock contention |
Date: | 2002-08-30 14:12:34 |
Message-ID: | 219.1030716754@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Manfred Koizar <mkoi-pg(at)aon(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-08-30 15:24:16 | Re: fix for palloc() of user-supplied length |
Previous Message | John Gray | 2002-08-30 12:22:56 | Re: Visibility regression test |