| From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
|---|---|
| To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
| Cc: | 'Amit Langote' <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, "Kato, Sho" <kato-sho(at)jp(dot)fujitsu(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: How to make partitioning scale better for larger numbers of partitions |
| Date: | 2018-07-13 06:15:43 |
| Message-ID: | 20180713061543.GX3890@telsasoft.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 in the current CF, though.) What challenges are there for future versions, and which of them are being addressed by patches in 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(dot)8020804%40strategicdata(dot)com(dot)au#4F989CD8(dot)8020804(at)strategicdata(dot)com(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2018-07-13 06:20:27 | Re: How to make partitioning scale better for larger numbers of partitions |
| Previous Message | amul sul | 2018-07-13 06:07:02 | Re: Cannot dump foreign key constraints on partitioned table |