From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jaime Casanova <jaime@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: foreign key locks
Date: Wed, 20 Jun 2012 12:54:24 -0400
Message-ID: <28415.1340211264@sss.pgh.pa.us> (raw)
In-Reply-To: <CAJKUy5jc=1jB9MhsQf0xLmGJDxsZP6wqbUDXPNw2n6WW5ORezg@mail.gmail.com>
References: <1339690386-sup-8927@alvh.no-ip.org>
<CAJKUy5jc=1jB9MhsQf0xLmGJDxsZP6wqbUDXPNw2n6WW5ORezg@mail.gmail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, jaime@2ndquadrant.com, alvherre@alvh.no-ip.org
Subject: Re: foreign key locks
In-Reply-To: <28415.1340211264@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox