From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | wrong Append/MergeAppend elision? |
Date: | 2023-01-26 12:27:43 |
Message-ID: | CA+HiwqFOtLbEk3fi8LOfe4XuX5NyTdQ1om21YtS4gdwL9kEq5g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Don-t-elide-Append-MergeAppend-if-run-time-prunin.patch | application/octet-stream | 10.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | torikoshia | 2023-01-26 13:00:04 | Re: Record queryid when auto_explain.log_verbose is on |
Previous Message | David Rowley | 2023-01-26 12:14:57 | Re: Considering additional sort specialisation functions for PG16 |