Re: 8.4 open item: copy performance regression?

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: 8.4 open item: copy performance regression?
Дата
Msg-id 407d949e0906200410x5be9ab88u2c6d19307823f8f5@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 8.4 open item: copy performance regression?  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: 8.4 open item: copy performance regression?  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
On Sat, Jun 20, 2009 at 9:22 AM, Simon Riggs<simon@2ndquadrant.com> wrote:
>> That would seem to me to be a more robust general approach for solving
>> this class of problem than the whole ring buffer idea, which is a great
>> start but bound to run into situations where the size of the buffer just
>> isn't right anymore a few hardware generations down the road.
>
> The ring buffer optimises L2 cache, not the buffer cache in general. If
> we put buffers back on the freelist that is the same as having one
> global ring buffer, which would then spoil the benefit for L2 on
> multi-CPU systems.

Incidentally a "ring buffer" is something else. We're talking about a
clock-sweep algorithm.

The whole point of the clock-sweep algorithm is that it's an
approximated LRU but with no single point of contention like a list
pointer. Doing this would be undermining that advantage.

I don't understand what you mean by "size of the buffer" either. The
only real parameter in the clock sweep algorithm is how many distinct
counter values there are. The more values the closer to an LRU the
result is. it isn't really tied to hardware in any way, just the usage
pattern.


-- 
greg
http://mit.edu/~gsstark/resume.pdf


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Markus Wanner
Дата:
Сообщение: Re: Synch Rep: communication between backends and walsender
Следующее
От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: 8.4 open item: copy performance regression?