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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD