On Tue, Sep 9, 2014 at 6:00 PM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2014-09-09 17:54:03 -0400, Robert Haas wrote: >> So, that's committed, then. > > Yay, finally. > >> I think we should pick something that uses >> spinlocks and is likely to fail spectacularly if we haven't got this >> totally right yet, and de-volatilize it. And then watch to see what >> turns red in the buildfarm and/or which users start screaming. > > Good plan. > >> I'm inclined to propose lwlock.c as a candidate, since that's very >> widely used and a place where we know there's significant contention. > > I suggest, additionally possibly, GetSnapshotData(). It's surely one of > the hottest functions in postgres, and I've seen some performance > increases from de-volatilizing it. IIRC it requires one volatile cast in > one place to enforce that a variable is accessed only once. Not sure if > we want to add such volatile casts or use something like linux' > ACCESS_ONCE macros for some common types. Helps to grep for places > worthy of inspection.
GetSnapshotData() isn't quite to the point, because it's using a volatile pointer, but not because of anything about spinlock manipulation. That would, perhaps, be a good test for barriers, but not for this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
