Date: Sat, 17 Nov 2012 17:07:18 +0100
From: Andres Freund <andres@2ndquadrant.com>
To: Noah Misch <noah@leadboat.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-hackers@postgresql.org
Subject: Re: foreign key locks
Message-ID: <20121117160718.GA5675@awork2.anarazel.de>
References: <1346389151-sup-8379@alvh.no-ip.org>
	<20121018195820.GO3763@alvh.no-ip.org>
	<201210270006.54728.andres@2ndquadrant.com>
	<20121114152347.GA5161@alvh.no-ip.org>
	<20121114162726.GE5161@alvh.no-ip.org>
	<20121116002459.GB4347@tornado.leadboat.com>
	<20121116161747.GC4454@alvh.no-ip.org>
	<20121116163112.GF6505@awork2.anarazel.de>
	<20121117033151.GB24972@tornado.leadboat.com>
	<20121117142020.GB4222@awork2.anarazel.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20121117142020.GB4222@awork2.anarazel.de>

> > 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