> > I agree that tripling FOR SHARE cost is risky. Where is the added cost > > concentrated? Perchance that multiple belies optimization opportunities. > > Good question, let me play a bit.
Ok, I benchmarked around and from what I see there is no single easy target. The biggest culprits I could find are: 1. higher amount of XLogInsert calls per transaction (visible in pgbench -t instead of -T mode while watching the WAL volume) 2. Memory allocations in GetMultiXactIdMembers 3. Memory allocations in mXactCachePut a) cache entry itself b) the cache context 4. More lwlocks acquisitions We can possibly optimize a bit with 2) by using a static buffer for common member sizes, but thats not going to buy us too much... 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
