Re: [HACKERS] PinBuffer() no longer makes use of strategy

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] PinBuffer() no longer makes use of strategy
Дата
Msg-id 20170204013342.wnhhvfnekynt56nk@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] PinBuffer() no longer makes use of strategy  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: [HACKERS] PinBuffer() no longer makes use of strategy  (Alexander Korotkov <aekorotkov@gmail.com>)
Re: [HACKERS] PinBuffer() no longer makes use of strategy  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
Hi,

On 2017-02-03 19:13:45 -0600, Jim Nasby wrote:
> No, I noticed it while reading code. Removing that does mean that if any
> non-default strategy (in any backend) hits that buffer again then the buffer
> will almost certainly migrate into the main buffer pool the next time one of
> the rings hits that buffer

Well, as long as the buffer is used from the ring, BufferAlloc() -
BufferAlloc() will reset the usagecount when rechristening the
buffer. So unless anything happens inbetween the buffer being remapped
last and remapped next, it'll be reused. Right?

The only case where I can see the old logic mattering positively is for
synchronized seqscans.  For pretty much else that logic seems worse,
because it essentially prevents any buffers ever staying in s_b when
only ringbuffer accesses are performed.

I'm tempted to put the old logic back, but more because this likely was
unintentional, not because I think it's clearly better.


> Also, shouldn't there be warnings or something from having a function
> argument that's never used?

No, that's actually fairly common in our codebase.


- Andres



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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] Time to up bgwriter_lru_maxpages?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Time to up bgwriter_lru_maxpages?