On Sat, Nov 17, 2012 at 05:07:18PM +0100, Andres Freund wrote: > > > 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...
In that case, +1 for your proposal to prop up FOR SHARE. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
