Postgres Pro
Downloads
Home   >   mailing lists

Re: simplifying foreign key/RI checks - Mailing list pgsql-hackers

From Keisuke Kuroda
Subject Re: simplifying foreign key/RI checks
Date
Msg-id CANDwgg+gF94y+C9iF6ChLnfra4FZU_GJRkPU0bP6hdeZnPibig@mail.gmail.com
Whole thread Raw
In response to Re: simplifying foreign key/RI checks  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: simplifying foreign key/RI checks  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
Tree view 
Hi, Amit-san,

Nice patch. I have confirmed that this solves the problem in [1] with
INSERT/UPDATE.

HEAD + patch
       name       | bytes | pg_size_pretty
------------------+-------+----------------
 CachedPlanQuery  | 10280 | 10 kB
 CachedPlanSource | 14616 | 14 kB
 CachedPlan       | 13168 | 13 kB ★ 710MB -> 13kB
(3 rows)

> > This patch completely sidesteps the DELETE case, which has more insidious performance implications, but is also far
lesscommon, and whose solution will likely be very different. 
>
> Yeah, we should continue looking into the ways to make referenced-side
> RI checks be less bloated.

However, as already mentioned, the problem of memory bloat on DELETE remains.
This can be solved by the patch in [1], but I think it is too much to apply
this patch only for DELETE. What do you think?

[1] https://www.postgresql.org/message-id/flat/cab4b85d-9292-967d-adf2-be0d803c3e23%40nttcom.co.jp_1

--
Keisuke Kuroda
NTT Software Innovation Center
keisuke.kuroda.3862@gmail.com

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: a misbehavior of partition row movement (?)
Next
From: Dilip Kumar
Date:
Subject: Re: Identify missing publications from publisher while create/alter subscription.