On 2014-07-02 09:27:52 +0300, Ants Aasma wrote: > On Fri, Jun 27, 2014 at 9:00 PM, Andres Freund <and...@2ndquadrant.com> wrote: > > Imagine the situation for the buffer header spinlock which is one of the > > bigger performance issues atm. We could aim to replace all usages of > > that with clever and complicated logic, but it's hard. > > > > The IMO reasonable (and prototyped) way to do it is to make the common > > paths lockless, but fall back to the spinlock for the more complicated > > situations. For the buffer header that means that pin/unpin and buffer > > lookup are lockless, but IO and changing the identity of a buffer still > > require the spinlock. My attempts to avoid the latter basically required > > a buffer header specific reimplementation of spinlocks. > > There is a 2010 paper [1] that demonstrates a fully non-blocking > approach to buffer management using the same generalized clock > algorithm that PostgreSQL has. The site also has an implementation for > Apache Derby. You may find some interesting ideas in there. > > [1] > http://code.google.com/p/derby-nb/source/browse/trunk/derby-nb/ICDE10_conf_full_409.pdf
Interesting. Thanks for the link. I think I had pretty much all the parts they described lockless as well (excluding the buffer mapping hashtable itself, which they didn't focus on either), it was just operations like replacing a dirty victim buffer where I fell back to the spinlock. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
