cached plans and enable_partition_pruning
От | Amit Langote |
---|---|
Тема | cached plans and enable_partition_pruning |
Дата | |
Msg-id | 46aaeac0-1fb8-fe95-540f-2d552746ccae@lab.ntt.co.jp обсуждение исходный текст |
Ответы |
Re: cached plans and enable_partition_pruning
|
Список | pgsql-hackers |
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? Thanks, Amit
Вложения
В списке pgsql-hackers по дате отправления: