Skip site navigation (1) Skip section navigation (2)

Re: our buffer replacement strategy is kind of lame

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: our buffer replacement strategy is kind of lame
Date: 2012-01-02 17:30:01
Message-ID: CA+U5nMKtvyDcV4zTr7bq7t6cA2nBfLxCJ8tQgVBnc5ddRPO+Bg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, Aug 14, 2011 at 7:33 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> Simon is proposing to bound the
> really bad case where you flip through the entire ring multiple times
> before you find a buffer, and that may well be worth doing.  But I
> think even scanning 100 buffers every time you need to bring something
> in is too slow.  What's indisputable is that a SELECT-only workload
> which is larger than shared_buffers can be very easily rate-limited by
> the speed at which BufFreelistLock can be taken and released.  If you
> have a better idea for solving that problem, I'm all ears...

I felt we were on the right track here for a while.

Does anyone dispute that BufFreelistLock is a problem? shared buffer
replacement is *not* O(k) and it definitely needs to be.

Does anyone have a better idea for reducing BufFreelistLock
contention? Something simple that will work for 9.2?

What steps are there between here and committing the freelist_ok.v2.patch?

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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-01-02 17:41:47
Subject: Re: our buffer replacement strategy is kind of lame
Previous:From: Andrew DunstanDate: 2012-01-02 17:17:34
Subject: Re: Review of VS 2010 support patches

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group