pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Amit Kapila <amit.kapila@huawei.com>
To: 'Robert Haas' <robertmhaas@gmail.com>
To: 'Greg Smith' <greg@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Page replacement algorithm in buffer cache
Date: Fri, 5 Apr 2013 10:42:14 +0530
Message-ID: <005701ce31bc$236753f0$6a35fbd0$@kapila@huawei.com> (raw)
In-Reply-To: <CA+Tgmob37KgvKQCCNiwpNAYPD5fmkyScq4Q9oXCqW+U5P4_L_g@mail.gmail.com>
References: <CAM-w4HM2A0rAGN-KRyDQfcH+8YsDvCJ4x=XYAsS+G2kp56qOjQ@mail.gmail.com>
	<CAHyXU0xMFvr2eiR+2Lv=dj+UON+muei_pjbUP2BMetiR-UTASw@mail.gmail.com>
	<29181.1363981925@sss.pgh.pa.us>
	<CAHyXU0yKC-HWk9hhBjUCPsnPMqhskvu_MEqB2cvmRu0d0+BsCw@mail.gmail.com>
	<29748.1363983378@sss.pgh.pa.us>
	<CAHyXU0wKmB5WXS+hAt2QmGfpTNdsz4Dx1nR3GCKvsNBOzt2ZbQ@mail.gmail.com>
	<CA+CSw_sMmHt-Up+SiyL4OPkrgfECQVnMeOpyJz+=M7x=DNTzWg@mail.gmail.com>
	<CAMkU=1zVSyNRR_AQh4j_w6h37+qyvAz4fY8A+QP8e0dsuBg7Fw@mail.gmail.com>
	<CAHyXU0xBXzuGAD8jJ82t2OEDyMmuY1=NwWYGwKte6xqsWWdU6w@mail.gmail.com>
	<20130401210920.GC7244@alap2.anarazel.de>
	<CAHyXU0zvW_Yv3Q5i+5DzTjaGmvjUZS+vRiVGq-WwNAj8A=iMmg@mail.gmail.com>
	<515A1393.9090908@nasby.net>
	<CAHyXU0zFmRFBJeGtWuwxey-8brcxS60Ve0vqT=wW+1v8P3E7UA@mail.gmail.com>
	<CA+TgmobVPCZ60eyDvwb6pfNnBuzanAxF8K8ey-Dd3t02E7fD+g@mail.gmail.com>
	<CAHyXU0ygrf+Fz52sxYHkRUbZJR+CG4GcK5a14Rsb+zsVh2Q8gg@mail.gmail.com>
	<CA+TgmoaB7RyE6stTO45uGT8TiC5VBGZpB+VDrbaeqxm80nT4Fw@mail.gmail.com>
	<515CDC20.5090005@2ndQuadrant.com>
	<CA+Tgmob37KgvKQCCNiwpNAYPD5fmkyScq4Q9oXCqW+U5P4_L_g@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

On Thursday, April 04, 2013 6:12 PM Robert Haas wrote:
> On Wed, Apr 3, 2013 at 9:49 PM, Greg Smith <greg@2ndquadrant.com>
> wrote:
> > On 4/2/13 11:54 AM, Robert Haas wrote:
> >> But, having said that, I still think the best idea is what Andres
> >> proposed, which pretty much matches my own thoughts: the bgwriter
> >> needs to populate the free list, so that buffer allocations don't
> have
> >> to wait for linear scans of the buffer array.
> >
> > I was hoping this one would make it to a full six years of being on
> the TODO
> > list before it came up again, missed it by a few weeks.  The funniest
> part
> > is that Amit even submitted a patch on this theme a few months ago
> without
> > much feedback:
> > http://www.postgresql.org/message-
> id/6C0B27F7206C9E4CA54AE035729E9C382852FF97@szxeml509-mbs
> > That stalled where a few things have, on a) needing more regression
> test
> > workloads, and b) wondering just what the deal with large
> shared_buffers
> > setting degrading performance was.
> 
> Those are impressive results.  I think we should seriously consider
> doing something like that for 9.4.  TBH, although more workloads to
> test is always better, I don't think this problem is so difficult that
> we can't have some confidence in a theoretical analysis.  If I read
> the original thread correctly (and I haven't looked at the patch
> itself), the proposed patch would actually invalidate buffers before
> putting them on the freelist.  That effectively amounts to reducing
> shared_buffers, so workloads that are just on the edge of what can fit
> in shared_buffers will be harmed, and those that benefit incrementally
> from increased shared_buffers will be as well.
> 
> What I think we should do instead is collect the buffers that we think
> are evictable and stuff them onto the freelist without invalidating
> them.  When a backend allocates from the freelist, it can double-check
> that the buffer still has usage_count 0.  The odds should be pretty
> good.  But even if we sometimes notice that the buffer has been
> touched again after being put on the freelist, we haven't expended all
> that much extra effort, and that effort happened mostly in the
> background.  

If we just put it to freelist, then next time if it get allocated directly
from bufhash table, then who will remove it from freelist
or do you think that, in BufferAlloc, if it gets from bufhash table, then it
should verify if it's in freelist, then remove from freelist.

With Regards,
Amit Kapila.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (82+ messages)  latest in thread

Message-ID: <005701ce31bc$236753f0$6a35fbd0$@kapila@huawei.com>
Permalink:  ../005701ce31bc$236753f0$6a35fbd0$@kapila@huawei.com/
Also on:    postgresql.org/message-id/005701ce31bc$236753f0$6a35fbd0$@kapila@huawei.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: amit.kapila@huawei.com, robertmhaas@gmail.com, greg@2ndquadrant.com
  Subject: Re: Page replacement algorithm in buffer cache
  In-Reply-To: <005701ce31bc$236753f0$6a35fbd0$@kapila@huawei.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox