| From: | Andres Freund <andres(at)anarazel(dot)de> | 
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> | 
| Cc: | Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com> | 
| Subject: | Re: PinBuffer() no longer makes use of strategy | 
| Date: | 2017-02-04 01:33:42 | 
| Message-ID: | 20170204013342.wnhhvfnekynt56nk@alap3.anarazel.de | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2017-02-04 01:34:46 | Re: Time to up bgwriter_lru_maxpages? | 
| Previous Message | Jim Nasby | 2017-02-04 01:26:55 | Re: Time to up bgwriter_lru_maxpages? |