Re: cached plans and enable_partition_pruning

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.
>
> create table p (a int) partition by list (a);
> create table p1 partition of p for values in (1);
> create table p1 partition of p for values in (2);
>
> -- force a generic plan so that run-time pruning is used in the plan
> reset enable_partition_pruning;
> set plan_cache_mode to force_generic_plan;
> prepare p as select * from p where a = $1;
>
> explain (costs off, analyze) execute p (1);
> QUERY PLAN
> ────────────────────────────────────────────────────────────────
> Append (actual time=0.079..0.106 rows=1 loops=1)
> Subplans Removed: 1
> -> Seq Scan on p2 (actual time=0.058..0.068 rows=1 loops=1)
> Filter: (a = $1)
> Planning Time: 17.573 ms
> Execution Time: 0.396 ms
> (6 rows)
>
> set enable_partition_pruning to off;
>
> explain (costs off, analyze) execute p (1);
> QUERY PLAN
> ────────────────────────────────────────────────────────────────
> Append (actual time=0.108..0.135 rows=1 loops=1)
> Subplans Removed: 1
> -> Seq Scan on p2 (actual time=0.017..0.028 rows=1 loops=1)
> Filter: (a = $1)
> Planning Time: 0.042 ms
> Execution Time: 0.399 ms
> (6 rows)
>
> Pruning still occurs, whereas one would expect it not to, because the plan
> (the Append node) contains run-time pruning information, which was
> initialized because enable_partition_pruning was turned on when the plan
> was created.
>
> 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?

Greetings,

Andres Freund