Re: Performance issues on FK Triggers after replacing a primary column - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Performance issues on FK Triggers after replacing a primary column
Date
Msg-id 80688616-f962-d567-0506-66c1e74b37b0@aklaver.com
Whole thread Raw
In response to Re: Performance issues on FK Triggers after replacing a primary column  (Per Kaminsky <per.kaminsky@hawk-intech.com>)
List pgsql-general
On 3/28/22 10:49 AM, Per Kaminsky wrote:
> The usage of "on update cascade" certainly sounds plausible. Since the 
> update does only happen rarely if there is a special need to completely 
> change the backend structure it is not added to the FK at the moment.
> Just ran the whole thing again with the "ANALYZE A; ANALYZE B" but with 
> no gain unfortunately.
> Just looking at the output i am also quite puzzled why an update to a 
> field in B which has no connection itself to A would trigger all the 
> foreign keys, except if this is a deferred call from updating A only now 
> triggered by touching data in B.
> 

An UPDATE in Postgres is essentially a DELETE of the old row version and 
an INSERT of the new row version. I'm going to guess the INSERT of the 
new row version fires the FK triggers on B.


-- 
Adrian Klaver
adrian.klaver@aklaver.com



pgsql-general by date:

Previous
From: Per Kaminsky
Date:
Subject: Re: Performance issues on FK Triggers after replacing a primary column
Next
From: Saurav Sarkar
Date:
Subject: Indexes in JSONB