Re: [9.5] possible fast path for pinning a page multiple times

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [9.5] possible fast path for pinning a page multiple times
Дата
Msg-id 12322.1401041806@sss.pgh.pa.us
обсуждение исходный текст
Ответ на [9.5] possible fast path for pinning a page multiple times  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> Idea:

> Let's say we have a routine PinBufferTag, that's like PinBuffer but it
> takes an additional BufferTag argument. When it locks the buffer header,
> it would also compare the argument to the buffer's tag, and if they
> don't match, return a status indicating that it's the wrong buffer and
> don't pin it. In other words, it pins the buffer only if it's the right
> one.

> Then, we can just have a backend-local cache that maps BufferTag to
> buffer ID. If it's missing an entry, or if the entry is wrong, then it
> just proceeds with the normal BufferAlloc path. But if the cache holds
> the right value, then we completely bypass the BufMappingPartitionLock
> while getting the pin.

> Before I do too much performance testing of this, is it a correct
> approach? It seems too easy.

Don't see why it wouldn't work.  I think you'd need to test buffer status
not just the contents of the tag field, but that's easy enough.

Bigger issues are how large we'd want to allow the local cache to get
(and what to do to keep it within that) and how much performance we
really gain.  But those are tuning questions not correctness questions.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg9.4b1: unhelpful error message when creating a collation
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: PATCH: pgbench / int64 instead of int for xact count