From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: cached plans and enable_partition_pruning |
Date: | 2018-07-23 18:43:07 |
Message-ID: | 20180723184307.ere3yfjy6dyfhmag@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-07-23 12:03:32 -0400, Alvaro Herrera wrote:
> On 2018-Jul-24, Amit Langote wrote:
>
> > On Mon, Jul 23, 2018 at 11:20 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> > > I think it's correct to check the plan time value, rather than the
> > > execution time value. Other enable_* GUCs also take effect there, and I
> > > don't see a problem with that?
> >
> > Ah, so that may have been intentional. Although, I wonder if
> > enable_partition_pruning could be made to work differently than other
> > enable_* settings, because we *can* perform pruning which is an
> > optimization function even during execution, whereas we cannot modify
> > the plan in other cases?
>
> Well, let's discuss the use-case for doing that. We introduced the GUC
> to cover for the case of bugs in the pruning code (and even then there
> was people saying we should remove it.) Why would you have the GUC
> turned on during planning but off during execution?
I think it's even more than that: It'd not be consistent to take it into
account at execution time, and there'd have to be very convincing
reasons to behave differently.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Nico Williams | 2018-07-23 19:02:40 | Re: How can we submit code patches that implement our (pending) patents? |
Previous Message | Peter Eisentraut | 2018-07-23 18:38:10 | Re: Making "COPY partitioned_table FROM" faster |