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 "A
___
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
On 3/27/22 23:53, Per Kaminsky wrote:
The table structure looks (roughly) like this:
* Table "Base": (id, created, deleted, origin, ...) ~3m rows
* Table "A": (id as FK on "Base", ...) ~400k rows
* Table "B": (id, ref_a as FK on "A", type, ...) ~2m rows
Swapping the PK of "A" happens as f
ly don't need the VERBOSE.
*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/28/22
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/
On 3/28/22 08:47, Per Kaminsky wrote:
The tables have Index to each other on each foreign key. The index
itself was not touched though, and a remove/recreate did not help. Could
it be possible, that when the PK and FK values are replaced the Index is
not (immediately) updated and thus cannot be
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
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
the table has million of rows but i removed most of them since otherwise
it would not finish sometime soon:
('Update on B (cost=0.00..71.50 r
Per Kaminsky writes:
> # ('Trigger for constraint B_firmid_fkey: time=25.592 calls=1000',)
> # ('Trigger for constraint B_type_fkey: time=14.899 calls=1000',)
> # ('Trigger for constraint B_userid_fkey: time=16.146 calls=1000',)
> # ('Trigger for constraint B_version_fkey: time=11.285 calls=1000',
ta state regarding the
program.
____________
From: Per Kaminsky
Sent: Monday, March 28, 2022 08:53
To: Adrian Klaver ; pgsql-gene...@postgresql.org
Subject: Re: Performance issues on FK Triggers after replacing a primary column
The table structure looks (roughly) like thi
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
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
12 matches
Mail list logo
