Postgres Pro
Downloads
Home   >   mailing lists

Re: Creating foreign key on partitioned table is too slow - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Creating foreign key on partitioned table is too slow
Date
Msg-id CA+HiwqF8+F-qDc9gcJ2dPWG7O8xU5b5nqJQ0CQkSXnRZy0CHmw@mail.gmail.com
Whole thread Raw
In response to RE: Creating foreign key on partitioned table is too slow  ("kato-sho@fujitsu.com" <kato-sho@fujitsu.com>)
Responses Re: Creating foreign key on partitioned table is too slow  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Tree view 
Hi Alvaro,

On Thu, Aug 6, 2020 at 4:25 PM kato-sho@fujitsu.com
<kato-sho@fujitsu.com> wrote:
> On Wednesday, August 5, 2020 9:43 AM I wrote:
> > I'll report the result before the end of August .
>
> I test v2-0001-build-partdesc-memcxt.patch at 9a9db08ae4 and it is ok.

Is this patch meant for HEAD or back-patching?  I ask because v13 got this:

commit 5b9312378e2f8fb35ef4584aea351c3319a10422
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Wed Dec 25 14:43:13 2019 -0500

    Load relcache entries' partitioning data on-demand, not immediately.

which prevents a partitioned table's PartitionDesc from being rebuilt
repeatedly as would happen before this commit in Kato-san's case,
because it moves RelationBuildPartitionDesc out of the relcache flush
code path.

So, the OOM situation that Kato-san original reported should not occur
as of v13.

-- 
Amit Langote
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: New statistics for tuning WAL buffer size
Next
From: Masahiro Ikeda
Date:
Subject: RE: New statistics for tuning WAL buffer size