Re: cached plans and enable_partition_pruning - Mailing list pgsql-hackers

From Amit Langote
Subject Re: cached plans and enable_partition_pruning
Date
Msg-id CA+HiwqHujtTFphE0U9zwqnk+R5NjzA2awgegerezz1EsPD=BZQ@mail.gmail.com
Whole thread Raw
In response to Re: cached plans and enable_partition_pruning  (Andres Freund <andres@anarazel.de>)
Responses Re: cached plans and enable_partition_pruning  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Mon, Jul 23, 2018 at 11:20 PM, Andres Freund <andres@anarazel.de> wrote:
> Hi,
>
> On 2018-07-23 18:31:43 +0900, Amit Langote wrote:
>> It seems that because enable_partition_pruning's value is only checked
>> during planning, turning it off *after* a plan is created and cached does
>> not work as expected.

[ ... ]

>> Should we check its value during execution too, as done in the attached?
>
> 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?

Thanks,
Amit


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: How can we submit code patches that implement our (pending)patents?
Next
From: Robert Haas
Date:
Subject: Re: pgbench - remove double declaration of hash functions