Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UJ80g-0004pL-St for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Mar 2013 19:52:19 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UJ80g-0000k0-AE for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Mar 2013 19:52:18 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UJ80f-0000ju-9C for pgsql-hackers@postgresql.org; Fri, 22 Mar 2013 19:52:17 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UJ80Z-0004Jq-5Q for pgsql-hackers@postgresql.org; Fri, 22 Mar 2013 19:52:16 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id r2MJq6Jc029182; Fri, 22 Mar 2013 15:52:06 -0400 (EDT) From: Tom Lane To: Merlin Moncure cc: Atri Sharma , Greg Stark , Ants Aasma , Amit Kapila , PostgreSQL-development Subject: Re: Page replacement algorithm in buffer cache In-reply-to: References: <514bf302.84d5440a.43f2.ffffe411SMTPIN_ADDED_BROKEN@mx.google.com> <08BBC126-D375-4743-B9A6-D1320D05D5C7@gmail.com> <514c3395.487a420a.28d1.764eSMTPIN_ADDED_BROKEN@mx.google.com> <3985.1363960959@sss.pgh.pa.us> Comments: In-reply-to Merlin Moncure message dated "Fri, 22 Mar 2013 14:05:56 -0500" Date: Fri, 22 Mar 2013 15:52:05 -0400 Message-ID: <29181.1363981925@sss.pgh.pa.us> X-Pg-Spam-Score: -4.4 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Merlin Moncure writes: > On Fri, Mar 22, 2013 at 1:13 PM, Atri Sharma wrote: >> What is the general thinking? Is it time to start testing again and >> thinking about improvements to the current algorithm? > well, what problem are you trying to solve exactly? the main problems > I see today are not so much in terms of page replacement but spinlock > and lwlock contention. Even back when we last hacked on that algorithm, the concerns were not so much about which pages it replaced as how much overhead and contention was created by the management algorithm. I haven't seen any reason to think we have a problem with the quality of the replacement choices. The proposal to increase the initial usage count would definitely lead to more overhead/contention, though, because it would result in having to circle around all the buffers more times (on average) to get a free buffer. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers