Re: Should we add GUCs to allow partition pruning to be disabled?
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, David Rowley <david.rowley@2ndquadrant.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-05-01T19:24:42Z
Lists: pgsql-hackers
On Tue, Apr 24, 2018 at 5:59 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > Constraint > exclusion was pretty easy to get wrong, hence the need for a separate > section, and I suppose the new partition pruning may be prey to the same > problems, so it seems worth to document them specially. But not sure > about the others, if they are mostly debugging tools. Weighing in here late, but I have a hard time understanding why we want a GUC to control partition pruning at all. With constraint exclusion, the issue is whether you want to spend planner cycles to try to deduce things using CHECK constraints when, quite possibly, your CHECK constraints are unrelated to table inheritance and thus won't help. But seems extremely unlikely that the same thing would happen with partition pruning. Unlike your CHECK constraints, your partition bounds are, by definition, potentially useful for pruning. -- 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