Re: How to make partitioning scale better for larger numbers ofpartitions
| От | Justin Pryzby |
|---|---|
| Тема | Re: How to make partitioning scale better for larger numbers ofpartitions |
| Дата | |
| Msg-id | 20180713061543.GX3890@telsasoft.com обсуждение исходный текст |
| Ответ на | RE: How to make partitioning scale better for larger numbers ofpartitions ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
| Список | 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 по дате отправления: