Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UN3yZ-00072s-N5 for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Apr 2013 16:22:24 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UN3yZ-0005XJ-0X for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Apr 2013 16:22:23 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UN3yX-0005WS-Jw for pgsql-hackers@postgresql.org; Tue, 02 Apr 2013 16:22:21 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UN3yO-0004N1-Si for pgsql-hackers@postgresql.org; Tue, 02 Apr 2013 16:22:21 +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 r32GM3WE003237; Tue, 2 Apr 2013 12:22:03 -0400 (EDT) From: Tom Lane To: Robert Haas cc: Merlin Moncure , Jim Nasby , Andres Freund , Jeff Janes , Ants Aasma , Atri Sharma , Greg Stark , Amit Kapila , PostgreSQL-development Subject: Re: Page replacement algorithm in buffer cache In-reply-to: References: <29181.1363981925@sss.pgh.pa.us> <29748.1363983378@sss.pgh.pa.us> <20130401210920.GC7244@alap2.anarazel.de> <515A1393.9090908@nasby.net> Comments: In-reply-to Robert Haas message dated "Tue, 02 Apr 2013 11:54:32 -0400" Date: Tue, 02 Apr 2013 12:22:03 -0400 Message-ID: <3236.1364919723@sss.pgh.pa.us> X-Pg-Spam-Score: -4.2 (----) 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 Robert Haas writes: > 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. That's just plain too > slow. I agree in general, though I'm not sure the bgwriter process can reasonably handle this need along with what it's already supposed to be doing. We may need another background process that is just responsible for keeping the freelist populated. 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