Re: Huge memory consumption on partitioned table with FKs

Amit Langote <amitlangote09@gmail.com>

From: Amit Langote <amitlangote09@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>, keisuke kuroda <keisuke.kuroda.3862@gmail.com>, tatsuhito.kasahara.rd@hco.ntt.co.jp
Date: 2020-12-07T16:16:00Z
Lists: pgsql-hackers
Hi Alvaro,

On Mon, Dec 7, 2020 at 23:48 Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

> On 2020-Dec-07, Amit Langote wrote:
>
> > On Fri, Dec 4, 2020 at 12:05 PM Kyotaro Horiguchi
> > <horikyota.ntt@gmail.com> wrote:
> > > > Also, the comment that was in RI_ConstraintInfo now appears in
> > > > RI_ConstraintParam, and the new struct (RI_ConstraintInfo) is now
> > > > undocumented.  What is the relationship between those two structs?  I
> > > > see that they have pointers to each other, but I think the
> relationship
> > > > should be documented more clearly.
> > >
> > > I'm not sure the footprint of this patch worth doing but here is a bit
> > > more polished version.
> >
> > I noticed that the foreign_key test fails and it may have to do with
> > the fact that a partition's param info remains attached to the
> > parent's RI_ConstraintInfo even after it's detached from the parent
> > table using DETACH PARTITION.
>
> I think this bit about splitting the struct is a distraction.  Let's get
> a patch that solves the bug first, and then we can discuss what further
> refinements we want to do.  I think we should get your patch in
> CA+HiwqEOrfN9b=f3sDmySPGc4gO-L_VMFHXLLxVmmdP34e64+w@mail.gmail.com
> committed (which I have not read yet.)  Do you agree with this plan?


Yeah, I agree.

- Amit

> --
Amit Langote
EDB: http://www.enterprisedb.com

Commits

  1. Avoid creating duplicate cached plans for inherited FK constraints.