Re: Should we add GUCs to allow partition pruning to be disabled?
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
David Rowley <david.rowley@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>,
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-12T15:07:11Z
Lists: pgsql-hackers
On Mon, Mar 11, 2019 at 12:30 AM Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: > Now the question is where to put this text? Currently, we have: > > 5.10. Table Partitioning > 5.10.1. Overview > 5.10.2. Declarative Partitioning > 5.10.3. Implementation Using Inheritance > 5.10.4. Partition Pruning > 5.10.5. Partitioning and Constraint Exclusion > > Should we add 5.10.6 Notes for the above "note", or should it be stuffed > under one of the existing sub-headings? 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Tweak partitioning documentation wording
- 12b9affb32a6 11.0 landed
-
docs: Rework sections on partition pruning/exclusion
- bebc46931a12 11.0 landed
-
Add GUC enable_partition_pruning
- 055fb8d33da6 11.0 landed