less performant than
recreating the FK constraint? If executed on 100k or even 1m rows the operation
takes hours or even days.
Thank you very much.
Sincerely, Per Kaminsky
TE "B" SET type = 2 WHERE type ISNULL;
ALTER TABLE "B" ADD CONSTRAINT "B_to_A_fkey" FOREIGN KEY (ref_a) REFERENCES
A(id);
____
From: Adrian Klaver
Sent: Sunday, March 27, 2022 23:22
To: Per Kaminsky ; pgsql-gene...@postgresql.org
Sub
o_A_fkey: time=27246.413 calls=1000',)
('Execution Time: 35884.978 ms',)
The tables have Index on each other. The vacuum can not be called, since all
those table modifications are part of one big transaction to be able to make a
rollback on any problem without causing an abnormal da
Kaminsky ; pgsql-gene...@postgresql.org
Subject: Re: Performance issues on FK Triggers after replacing a primary column
On 3/28/22 00:22, Per Kaminsky wrote:
> Sorry, i forgot to add the following:
>
> Explain / Analyze for the last "update type on B" call, normally there
> th
transaction (which i
don't know if that is the case).
From: Adrian Klaver
Sent: Monday, March 28, 2022 17:59
To: Per Kaminsky ; pgsql-gene...@postgresql.org
; Tom Lane
Subject: Re: Performance issues on FK Triggers after replacing a primary column
On 3/
___
From: Adrian Klaver
Sent: Monday, March 28, 2022 18:49
To: Per Kaminsky ; pgsql-gene...@postgresql.org
Subject: Re: Performance issues on FK Triggers after replacing a primary column
On 3/27/22 23:53, Per Kaminsky wrote:
> The table structure looks (roughly) like this:
&g
