Re: foreign key locks
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jaime Casanova <jaime@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-06-20T16:54:24Z
Lists: pgsql-hackers
Jaime Casanova <jaime@2ndquadrant.com> writes: > On Thu, Jun 14, 2012 at 11:41 AM, Alvaro Herrera > <alvherre@alvh.no-ip.org> 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 <CAEZATCWm8M00RA814o4DC2cD_aj44gQLb0tDdxMHA312qg7HCQ@mail.gmail.com> 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