Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 7998F8B63D8 for ; Wed, 20 Jun 2012 13:54:44 -0300 (ADT) Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1ShOAz-00025g-KV for pgsql-hackers@postgresql.org; Wed, 20 Jun 2012 16:54:43 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q5KGsPt9028416; Wed, 20 Jun 2012 12:54:25 -0400 (EDT) From: Tom Lane To: Jaime Casanova cc: Alvaro Herrera , Pg Hackers Subject: Re: foreign key locks In-reply-to: References: <1339690386-sup-8927@alvh.no-ip.org> Comments: In-reply-to Jaime Casanova message dated "Wed, 20 Jun 2012 09:28:04 -0500" Date: Wed, 20 Jun 2012 12:54:24 -0400 Message-ID: <28415.1340211264@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201206/1177 X-Sequence-Number: 210017 Jaime Casanova writes: > On Thu, Jun 14, 2012 at 11:41 AM, Alvaro Herrera > wrote: >> This is v12 of the foreign key locks patch. > Just noticed that this patch needs a rebase because of the refactoring > Tom did in ri_triggers.c Hold on a bit before you work on that code --- I've got one more bit of hacking I want to try before walking away from it. I did some oprofile work on Dean's example from and noticed that it looks like ri_FetchConstraintInfo is eating a noticeable fraction of the runtime, which is happening because it is called to deconstruct the relevant pg_constraint row for each tuple we consider firing the trigger for (and then again, if we do fire the trigger). I'm thinking it'd be worth maintaining a backend-local cache for the deconstructed data, and am going to go try that. regards, tom lane