On Sat, 20 Jun 2009, Simon Riggs wrote:
The reason for not doing that would be that we don't know that the blocks are free to use; we know very little about them. The longer we leave them the more likely they are to be reused, so putting buffers onto the freelist when they aren't actually free would likely make the cache less effective, ISTM.
This is the prevailing wisdom. The current design of the background writer tries to make a reasonable guess as to how many buffers are going to be allocated in the next bg_writer_delay period, and it locates/generates clean buffers to fill that expected need. The idea would be to put those buffers, which have a good chance of being allocated by somebody else and therefore invalided shortly, onto the free list.
There's a certain amount of overhead the backends themselves wait for in order to advance the clock sweep position to find the buffers they need, and that adds some latency to them. I would guess there's some potential for reducing that latency if the freelist was sometimes populated, which right now it rarely is. While that would add contention onto the free list, I wonder if it might still be less than the contention on advancing the current buffer pool strategy point.
I don't want to go through the whole thing in this thread, just pointing out some similarity with an item I'd already proposed onto the TODO list--and that a good solution there might get rid of this whole "how big do I make the ring buffer?" situation. Obviously actual measurements here would trump any theorizing as to what works better, it's hard to get any intuition about low-level optimizing given how complicated CPU caches are nowadays.
-- * Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
