Skip site navigation (1) Skip section navigation (2)

Re: Optimize referential integrity checks (todo item)

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Vik Reykja <vikreykja(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>,PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimize referential integrity checks (todo item)
Date: 2012-08-27 18:09:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Any status on this?


On Mon, Feb 13, 2012 at 04:34:51PM +0100, Vik Reykja wrote:
> On Mon, Feb 13, 2012 at 15:25, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>     On Sat, Feb 11, 2012 at 9:06 PM, Vik Reykja <vikreykja(at)gmail(dot)com> wrote:
>     > I decided to take a crack at the todo item created from the following
>     post:
>     >
>     >
>     > The attached patch makes the desired changes in both code and function
>     > naming.
>     >
>     > It seemed quite easy to do but wasn't marked as easy on the todo, so I'm
>     > wondering if I've missed something.
>     It's kind of hard to say whether you've missed something, because you
>     haven't really explained what problem this is solving; the thread you
>     linked too isn't very clear about that either.  At first blush, it
>     seems like you've renamed a bunch of stuff without making very much
>     change to what actually happens.  Changing lots of copies of "equal"
>     to "unchanged" doesn't seem to me to be accomplishing anything.
> It's very simple really, and most of it is indeed renaming the functions.  The
> "problem" this solves is that foreign key constraints are sometimes checked
> when they don't need to be.  See my example below.
>     > All regression tests pass.
>     You should add some new ones showing how this patch improves the
>     behavior relative to the previous code.  Or if you can't, then you
>     should provide a complete, self-contained test case that a reviewer
>     can use to see how your proposed changes improve things.
> I have no idea how a regression test would be able to see this change, so
> here's a test case that you can follow with the debugger.
> /* initial setup */
> create table a (x int, y int, primary key (x, y));
> create table b (x int, y int, z int, foreign key (x, y) references a);
> insert into a values (1, 2);
> insert into b values (1, null, 3);
> /* seeing the difference */
> update b set z=0;
> When that update is run, it will check if the FK (x, y) has changed to know if
> it needs to verify that the values are present in the other table.  The
> equality functions that do that don't consider two nulls to be equal (per sql
> logic) and so reverified the constraint.  Tom noticed that it didn't need to
> because it hadn't really changed.
> In the above example, the current code will recheck the constraint and the new
> code won't.  It's not really testing equality anymore (because null does not
> equal null), so I renamed them causing a lot of noise in the diff.
>     We're in the middle of a CommitFest right now,
> Yes, I wasn't expecting this to be committed, I just didn't want to lose track
> of it.
>     so please add this patch to the next one if you would like it reviewed:
> Will do.

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + It's impossible for everything to be true. +

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2012-08-27 18:31:59
Subject: Re: pg_upgrade's exec_prog() coding improvement
Previous:From: Pavel StehuleDate: 2012-08-27 17:50:19
Subject: Re: temporal support patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group