Re: PinBuffer() no longer makes use of strategy

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(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 19:47:47
Message-ID: CAPpHfds5M6vHpFTTsoGSBmAX+t=YCk=K9hPnTJCN4MCEx0c=xg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 4, 2017 at 4:33 AM, Andres Freund <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.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Attachment Content-Type Size
put-buffer-usagecount–logic–back.patch application/octet-stream 1.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2017-02-04 19:54:25 Re: Provide list of subscriptions and publications in psql's completion
Previous Message Tom Lane 2017-02-04 18:24:48 Re: Index corruption with CREATE INDEX CONCURRENTLY