From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jaime Casanova <jaime(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: foreign key locks |
Date: | 2012-06-20 16:54:24 |
Message-ID: | 28415.1340211264@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jaime Casanova <jaime(at)2ndquadrant(dot)com> writes:
> On Thu, Jun 14, 2012 at 11:41 AM, Alvaro Herrera
> <alvherre(at)alvh(dot)no-ip(dot)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(at)mail(dot)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2012-06-20 16:56:52 | Re: Nasty, propagating POLA violation in COPY CSV HEADER |
Previous Message | Andrew Dunstan | 2012-06-20 16:54:23 | Re: Nasty, propagating POLA violation in COPY CSV HEADER |