Re: our buffer replacement strategy is kind of lame

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: our buffer replacement strategy is kind of lame
Дата
Msg-id CA+U5nMKEE+59N176Xe-onSOyBW0Z-QUDHG3-+s=L0zGWnk2Xmw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: our buffer replacement strategy is kind of lame  (Simon Riggs <simon@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Jean-Baptiste Quenot
Дата:
Сообщение: Re: plpython crash
Следующее
От: Marko Kreen
Дата:
Сообщение: Re: sha1, sha2 functions into core?