Re: How to make partitioning scale better for larger numbers ofpartitions - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: How to make partitioning scale better for larger numbers ofpartitions
Date
Msg-id 20180713061543.GX3890@telsasoft.com
Whole thread Raw
In response to RE: How to make partitioning scale better for larger numbers ofpartitions  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
On Fri, Jul 13, 2018 at 05:49:20AM +0000, Tsunakawa, Takayuki wrote:
> David has submitted multiple patches for PG 12, one of which speeds up pruning of UPDATE/DELETE (I couldn't find it
inthe current CF, though.)  What challenges are there for future versions, and which of them are being addressed by
patchesin progress for PG 12, and which issues are untouched?
 

Here's an known issue which I'm not sure is on anybody's list:

https://www.postgresql.org/message-id/flat/4F989CD8.8020804%40strategicdata.com.au#4F989CD8.8020804@strategicdata.com.au
=> planning of UPDATE/DELETE (but not SELECT) takes huge amount of RAM when run
on parent with many childs.

We don't typically have UPDATEs, and those we do are against the child tables;
but ran into this last month with a manual query on parent causing OOM.  I
worked around it, but keep meaning to revisit to see if this changed at all in
v11 (very brief testing suggests not changed).

Justin


pgsql-hackers by date:

Previous
From: amul sul
Date:
Subject: Re: Cannot dump foreign key constraints on partitioned table
Next
From: David Rowley
Date:
Subject: Re: How to make partitioning scale better for larger numbers of partitions