Re: Tweaking Foreign Keys for larger tables

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Tweaking Foreign Keys for larger tables
Date: 2014-11-05 21:15:38
Message-ID: 545A937A.6080502@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/31/14 6:19 AM, Simon Riggs wrote:
> Various ways of tweaking Foreign Keys are suggested that are helpful
> for larger databases.

> * INITIALLY NOT ENFORCED
> FK created, but is not enforced during DML.
> Will be/Must be marked NOT VALID when first created.
> We can run a VALIDATE on the constraint at any time; if it passes the
> check it is marked VALID and presumed to stay that way until the next
> VALIDATE run.

Does that mean the FK would become invalid after every DML operation,
until you expicitly revalidate it? Is that practical?

> ON DELETE IGNORE
> ON UPDATE IGNORE
> If we allow this specification then the FK is "one way" - we check the
> existence of a row in the referenced table, but there is no need for a
> trigger on the referenced table to enforce an action on delete or
> update, so no need to lock the referenced table when adding FKs.

Are you worried about locking the table at all, or about having to lock
many rows?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message philip taylor 2014-11-05 21:31:23 Amazon Redshift
Previous Message Peter Geoghegan 2014-11-05 21:09:51 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}