From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Tweaking Foreign Keys for larger tables |
Date: | 2014-11-06 17:28:03 |
Message-ID: | 545BAFA3.2050508@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/6/14, 2:58 AM, Simon Riggs wrote:
> On 5 November 2014 21:15, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> 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?
>
> I think so.
>
> We store the validity on the relcache entry.
>
> Constraint would add a statement-level after trigger for insert,
> update, delete and trigger, which issues a relcache invalidation if
> the state was marked valid. Marked as deferrable initially deferred.
I don't think you'd need to invalidate on insert, or on an update that didn't touch a referenced key.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-11-06 17:31:25 | Re: split builtins.h to quote.h |
Previous Message | Julien Rouhaud | 2014-11-06 17:12:36 | Re: split builtins.h to quote.h |