Re: our buffer replacement strategy is kind of lame

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 for PG 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 back out 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 free list.
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net