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

From Jim Nasby
Subject Re: our buffer replacement strategy is kind of lame
Date
Msg-id 37620154-1787-41D7-9477-18167E44D423@nasby.net
Whole thread Raw
In response to Re: our buffer replacement strategy is kind of lame  (Robert Haas <robertmhaas@gmail.com>)
Responses 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>)
List 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 by date:

Previous
From: Brad Davis
Date:
Subject: Re: [patch] Improve documentation around FreeBSD Kernel Tuning
Next
From: Peter Eisentraut
Date:
Subject: Re: controlling the location of server-side SSL files