___
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
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/
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
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
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
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
