| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, David Rowley <david(dot)rowley(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: | 2018-05-01 19:24:42 |
| Message-ID: | CA+TgmoZQ1kzA3DhHPNJ5=06tTLU8FEQSTJX4zUCJPqR426_PCA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 24, 2018 at 5:59 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2018-05-01 19:43:43 | Re: Global snapshots |
| Previous Message | Robert Haas | 2018-05-01 19:08:46 | Re: power() function in Windows: "value out of range: underflow" |