Re: our buffer replacement strategy is kind of lame - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: our buffer replacement strategy is kind of lame
Date
Msg-id CA+U5nMKEE+59N176Xe-onSOyBW0Z-QUDHG3-+s=L0zGWnk2Xmw@mail.gmail.com
Whole thread Raw
In response to Re: our buffer replacement strategy is kind of lame  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On Fri, Aug 12, 2011 at 11:53 AM, Simon Riggs <simon@2ndquadrant.com> wrote:

> I've not been reading "the literature", given the problems we had in
> 2004/5 regarding patents in this area. I also think that since we rely
> on the underlying filesystem for cacheing that we don't have exactly
> the same problem as other systems.

Reading the link you gave, I'm unimpressed by ClockPro. The
measurements made are all in low numbers of MB and the results show
that Clock is roughly same or better for large caches, but one might
read them multiple ways.

The zone of interest for us is above 1GB and the issues we care about
are contention, so even if we think ClockPro has a chance of improving
things we really don't have any measurements that support the cases we
care about.

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


pgsql-hackers by date:

Previous
From: Jean-Baptiste Quenot
Date:
Subject: Re: plpython crash
Next
From: Marko Kreen
Date:
Subject: Re: sha1, sha2 functions into core?