Re: Performance issues on FK Triggers after replacing a primary column

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Per Kaminsky <per(dot)kaminsky(at)hawk-intech(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Performance issues on FK Triggers after replacing a primary column
Date: 2022-03-27 21:22:44
Message-ID: 8ed0c2ae-8a35-2628-4b41-68f9cb734297@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 3/27/22 09:30, Per Kaminsky wrote:
> Hi there,
>
> i recently stumbled upon a performance issue which i can't
> really understand.
> The issue occured when i (roughly) did the following without a commit in
> between:
>
> * Replace the PK column of a table A which has a referencing table B -
> I have removed the FK from the referencing tables B and have
> recreated them afterwards
> * Now following i am working in one of the referencing tables B,
> updating columns. This takes an extremely large amount of time. This
> means, e.g. updating 1000 rows would now need 35-40 seconds.
> * The "explain" tells, that the Foreign Key trigger in B referencing A
> causes this mishap.

Post the query and the explain.

Also have you run vacuum and/or analyze on the tables involved?

> * Re-creating the Index in B for the column referencing A does not
> cause any performance gain.
> * If i again remove the FK to A from B this again shrinks back to some
> milliseconds.
>
> The question is, what does cause the FK trigger to be 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
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Peter J. Holzer 2022-03-27 23:34:16 Re: support for DIN SPEC 91379 encoding
Previous Message Bzm@g 2022-03-27 18:08:05 Re: support for DIN SPEC 91379 encoding