Re: Slightly reduce BufMgrLock contention
От | Tom Lane |
---|---|
Тема | Re: Slightly reduce BufMgrLock contention |
Дата | |
Msg-id | 219.1030716754@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Slightly reduce BufMgrLock contention (Manfred Koizar <mkoi-pg@aon.at>) |
Ответы |
Re: Slightly reduce BufMgrLock contention
|
Список | 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 по дате отправления: