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

help / color / mirror / Atom feed
From: Andres Freund <andres@2ndquadrant.com>
To: Greg Stark <stark@mit.edu>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Merlin Moncure <mmoncure@gmail.com>
Cc: Jim Nasby <jim@nasby.net>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: Ants Aasma <ants@cybertec.at>
Cc: Atri Sharma <atri.jiit@gmail.com>
Cc: Amit Kapila <amit.kapila@huawei.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Page replacement algorithm in buffer cache
Date: Tue, 2 Apr 2013 19:35:10 +0200
Message-ID: <20130402173510.GI2415@alap2.anarazel.de> (raw)
In-Reply-To: <CAM-w4HNxFckMid3DEq8tOM3vsFdPY+EzV0NTkbmwCWOqp8yAeA@mail.gmail.com>
References: <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+TgmoaB7R!yE6stTO45uGT8TiC5VBGZpB+VDrbaeqxm80nT4Fw@mail.gmail.com>
	<3236.1364919723@sss.pgh.pa.us>
	<20130402163609.GG2415@alap2.anarazel.de>
	<3949.1364921816@sss.pgh.pa.us>
	<CAM-w4HNxFckMid3DEq8tOM3vsFdPY+EzV0NTkbmwCWOqp8yAeA@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

On 2013-04-02 18:26:23 +0100, Greg Stark wrote:
> I'm confused by this thread. We *used* to maintain an LRU. The whole
> reason for the clock-sweep algorithm is precisely to avoid maintaining
> a linked list of least recently used buffers since the head of that
> list is a point of contention.

I don't think anybody is proposing to put the LRU back into a linked list,
given the frequency of usagecount manipulations that would probably end pretty
badly. What I think Robert, Tom and I are talking are talking about is putting
*some* buffers with usagecount = 0 into a linked list so that when a backend
requires a new page it can take one buffer from the freelist instead of

a) possibly touching quite some (I have seen 4 times *every* existing header)
pages to find one with usagecount = 0
b) having to write the page out itself

If everything is going well that would mean only the bgwritter (or if
bgfreelist or whatever) performs the clock sweep. Others take *new* pages from
the freelist instead of performing part of the sweep themselves.

Makes more sense?

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
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: <20130402173510.GI2415@alap2.anarazel.de>
Permalink:  ../20130402173510.GI2415@alap2.anarazel.de/
Also on:    postgresql.org/message-id/20130402173510.GI2415@alap2.anarazel.de

 · 

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: andres@2ndquadrant.com, stark@mit.edu, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, mmoncure@gmail.com, jim@nasby.net, jeff.janes@gmail.com, ants@cybertec.at, atri.jiit@gmail.com, amit.kapila@huawei.com
  Subject: Re: Page replacement algorithm in buffer cache
  In-Reply-To: <20130402173510.GI2415@alap2.anarazel.de>

* 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