Re: our buffer replacement strategy is kind of lame

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: our buffer replacement strategy is kind of lame
Дата
Msg-id 37620154-1787-41D7-9477-18167E44D423@nasby.net
обсуждение исходный текст
Ответ на Re: our buffer replacement strategy is kind of lame  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: our buffer replacement strategy is kind of lame  (Robert Haas <robertmhaas@gmail.com>)
Re: our buffer replacement strategy is kind of lame  (Greg Smith <greg@2ndQuadrant.com>)
Список pgsql-hackers
On Jan 3, 2012, at 11:15 AM, Robert Haas wrote:
>> So you don't think a freelist is worth having, but you want a list of
>> allocation targets.
>> What is the practical difference?
>
> I think that our current freelist is practically useless, because it
> is almost always empty, and the cases where it's not empty (startup,
> and after a table or database drop) are so narrow that we don't really
> get any benefit out of having it.  However, I'm not opposed to the
> idea of a freelist in general: I think that if we actually put in some
> effort to keep the freelist in a non-empty state it would help a lot,
> because backends would then have much less work to do at buffer
> allocation time.

This is exactly what the FreeBSD VM system does (which is at least one of the places where the idea of a clock sweep
forPG came from ages ago). There is a process that does nothing but attempt to keep X amount of memory on the free
list,where it can immediately be grabbed by anything that needs memory. Pages on the freelist are guaranteed to be
clean(as in not dirty), but not zero'd. In fact, IIRC if a page on the freelist gets referenced again it can be pulled
backout of the free list and put back into an active state. 

The one downside I see to this is that we'd need some heuristic to determine how many buffers we want to keep on the
freelist. 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




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

Предыдущее
От: Brad Davis
Дата:
Сообщение: Re: [patch] Improve documentation around FreeBSD Kernel Tuning
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: controlling the location of server-side SSL files