Re: Should we add GUCs to allow partition pruning to be disabled? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Should we add GUCs to allow partition pruning to be disabled?
Date
Msg-id CA+TgmoZQ1kzA3DhHPNJ5=06tTLU8FEQSTJX4zUCJPqR426_PCA@mail.gmail.com
Whole thread Raw
In response to Re: Should we add GUCs to allow partition pruning to be disabled?  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Should we add GUCs to allow partition pruning to be disabled?  (David Rowley <david.rowley@2ndquadrant.com>)
Re: Should we add GUCs to allow partition pruning to be disabled?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List 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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: power() function in Windows: "value out of range: underflow"
Next
From: Robert Haas
Date:
Subject: Re: Global snapshots