On Sun, Aug 14, 2011 at 7:33 PM, Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
