Re: Tweaking Foreign Keys for larger tables - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Tweaking Foreign Keys for larger tables
Date
Msg-id 545A937A.6080502@gmx.net
Whole thread Raw
In response to Tweaking Foreign Keys for larger tables  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Tweaking Foreign Keys for larger tables  (David G Johnston <david.g.johnston@gmail.com>)
Re: Tweaking Foreign Keys for larger tables  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Tweaking Foreign Keys for larger tables  (Simon Riggs <simon@2ndQuadrant.com>)
List 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?




pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Next
From: "philip taylor"
Date:
Subject: Amazon Redshift