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