wrong Append/MergeAppend elision?

Поиск
Список
Период
Сортировка
От Amit Langote
Тема wrong Append/MergeAppend elision?
Дата
Msg-id CA+HiwqFOtLbEk3fi8LOfe4XuX5NyTdQ1om21YtS4gdwL9kEq5g@mail.gmail.com
обсуждение исходный текст
Ответы Re: wrong Append/MergeAppend elision?  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
Hi,

It seems that the planner currently elides an Append/MergeAppend that
has run-time pruning info (part_prune_index) set, but which I think is
a bug.  Here's an example:

create table p (a int) partition by list (a);
create table p1 partition of p for values in (1);
set plan_cache_mode to force_generic_plan ;
prepare q as select * from p where a = $1;
explain execute q (0);
                      QUERY PLAN
------------------------------------------------------
 Seq Scan on p1 p  (cost=0.00..41.88 rows=13 width=4)
   Filter: (a = $1)
(2 rows)

Because the Append is elided in this case, run-time pruning doesn't
kick in to prune p1, even though PartitionPruneInfo to do so has been
generated.

Attached find a patch to fix that.  There are some expected output
diffs in partition_prune suite, though they all look sane to me.

Thoughts?

-- 
Thanks, Amit Langote
EDB: http://www.enterprisedb.com

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Considering additional sort specialisation functions for PG16
Следующее
От: torikoshia
Дата:
Сообщение: Re: Record queryid when auto_explain.log_verbose is on