From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Cc: | Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, 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-03-16 17:48:54 |
Message-ID: | 72a729ac-62ca-5241-8c1f-a3187f3c0462@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/4/17 2:47 PM, Alexander Korotkov wrote:
> On Sat, Feb 4, 2017 at 4:33 AM, Andres Freund <andres(at)anarazel(dot)de
> <mailto:andres(at)anarazel(dot)de>> wrote:
>
> 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.
>
>
> +1
> Yes, it was unintentional change. So we should put old logic back
> unless we have proof that this change make it better.
> Patch is attached. I tried to make some comments, but probably they are
> not enough.
This patch looks pretty straight forward and applies cleanly and
compiles at cccbdde.
It's not a straight revert, though, so still seems to need review.
Jim, do you know when you'll have a chance to look at that?
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2017-03-16 17:50:15 | Re: Parallel Bitmap scans a bit broken |
Previous Message | Robert Haas | 2017-03-16 17:35:23 | Re: Push down more full joins in postgres_fdw |