From: Amit Kapila <amit.kapila@huawei.com>
To: "'Greg Smith'" <greg@2ndQuadrant.com>, <pgsql-hackers@postgresql.org>
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>
In-Reply-To: <515CDC20.5090005@2ndQuadrant.com>
Subject: Re: Page replacement algorithm in buffer cache
Date: Thu, 4 Apr 2013 15:04:46 +0530
Message-ID: <008e01ce3117$a5941fc0$f0bc5f40$@kapila@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Ac4w1rNS23jEuKUJQHKC1KyUZfT3OAAP3VeQ
Content-Language: en-us
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On Thursday, April 04, 2013 7:19 AM Greg Smith 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.

For "b)", below are links where it decreased due to large shared buffers.

http://www.postgresql.org/message-id/attachment/27489/Results.htm
http://www.postgresql.org/message-id/6C0B27F7206C9E4CA54AE035729E9C38285442C
5@szxeml509-mbx


As per my observation, it occur when I/O starts. The dip could be due to
fluctuation or may be due to some OS scheduling or it could be due to
Eviction of dirty pages sooner than it would otherwise.

I think the further investigation can be more meaningful if the results can
be taken by someone else other than me.

One idea to proceed in this line could be we start with this patch and then
based on results, do the further experiments to make it more useful.  

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