> > 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 mXactCachePuta) cache entry itselfb) 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
