[Greg Smith <greg@2ndQuadrant.com>]

On 5/14/13 9:42 AM, Amit Kapila wrote:
> In the attached patch, bgwriter/checkpointer moves unused (usage_count
> =0 && refcount = 0) buffer’s to end of freelist. I have implemented a
> new API StrategyMoveBufferToFreeListEnd() to

There's a comment in the new function:

It is possible that we are told to put something in the freelist that
is already in it; don't screw up the list if so.

I don't see where the code does anything to handle that though.  What 
was your intention here?

This area has always been the tricky part of the change.  If you do 
something complicated when adding new entries, like scanning the 
freelist for duplicates, you run the risk of holding BufFreelistLock for 
too long.  To try and see that in benchmarks, I would use a small 
database scale (I typically use 100 for this type of test) and a large 
number of clients.  "-M prepared" would help get a higher transaction 
rate out of the hardware too.  It might take a server with a large core 
count to notice any issues with holding the lock for too long though.

Instead you might just invalidate buffers before they go onto the list. 
  Doing that will then throw away usefully cached data though.

To try and optimize both insertion speed and retaining cached data, I 
was thinking about using a hash table for the free buffers, instead of 
the simple linked list approach used in the code now.

Also:  check the formatting on the additions to in bufmgr.c, I noticed a 
spaces vs. tabs difference on lines 35/36 of your patch.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers