| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: foreign key locks |
| Date: | 2012-11-17 16:07:18 |
| Message-ID: | 20121117160718.GA5675@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Karl O. Pinc | 2012-11-17 17:33:04 | Re: Doc patch, put pg_temp into the documentation's index |
| Previous Message | Любен Каравелов | 2012-11-17 16:01:41 | Re: Parser - Query Analyser |