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
Re: [HACKERS] PinBuffer() no longer makes use of strategy |
Список | 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 по дате отправления: