Re: foreign key locks

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: foreign key locks
Date: 2012-06-21 19:47:09
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Excerpts from Tom Lane's message of mié jun 20 12:54:24 -0400 2012:
> 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.

I had merged already when I got your email, but merging that additional
change did not cause any conflicts. So here's the rebased version.

Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Attachment Content-Type Size
fklocks-13.patch.gz application/x-gzip 88.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2012-06-21 20:43:07 Re: pl/perl and utf-8 in sql_ascii databases
Previous Message Alexander Korotkov 2012-06-21 18:53:43 Re: Incorrect behaviour when using a GiST index on points