Re: 8.4 open item: copy performance regression?

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