From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Should we add GUCs to allow partition pruning to be disabled? |
Date: | 2019-03-12 23:28:31 |
Message-ID: | CAKJS1f9Mh2uYMfcoCYzGXeZgab=TtcFChE=rDxC3py4UK+vW-Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 13 Mar 2019 at 04:07, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I think it should be added to one of the existing sub-headings. I
> suggest adding it to the end of 5.10.1 and rephrasing it so that it
> makes clearer the distinction between what will happen with
> inheritance and what will happen with table partitioning, e.g.
>
> When using either declarative partitioning or table inheritance,
> partitioning hierarchies with more than a few hundred partitions are
> not currently recommended. Larger partition hierarchies may incur long
> planning time, and especially in the case of UPDATE and DELETE,
> excessive memory usage. When inheritance is used, see also the
> limitations described in Section 5.10.5, Partitioning and Constraint
> Exclusion.
I think I've done that in the attached patch. However, do think the
just saying "excessive memory usage" seems strange without prefixing
it with "can result in" and dropping the "especially". I'm fairly
used to having my wording debated, so I've left your words in the
patch.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachment | Content-Type | Size |
---|---|---|
docs_partitioning_warning.patch | application/octet-stream | 958 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2019-03-12 23:40:57 | Re: Introduce timeout capability for ConditionVariableSleep |
Previous Message | Shawn Debnath | 2019-03-12 23:24:54 | Introduce timeout capability for ConditionVariableSleep |