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
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2012-01-02 17:41:47|
|Subject: Re: our buffer replacement strategy is kind of lame |
|Previous:||From: Andrew Dunstan||Date: 2012-01-02 17:17:34|
|Subject: Re: Review of VS 2010 support patches|