From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Sergei Glukhov <s(dot)glukhov(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Problem, partition pruning for prepared statement with IS NULL clause. |
Date: | 2023-10-08 23:26:24 |
Message-ID: | CAApHDvrc8BjkN8U3NUVzvat3EtC7bzLwFdUw_OFf3Sv-QCp-Vg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 7 Oct 2023 at 03:11, Sergei Glukhov <s(dot)glukhov(at)postgrespro(dot)ru> wrote:
> I noticed that combination of prepared statement with generic plan and
> 'IS NULL' clause could lead partition pruning to crash.
> Test case:
> ------
> set plan_cache_mode to force_generic_plan;
> prepare stmt AS select * from hp where a is null and b = $1;
> explain execute stmt('xxx');
Thanks for the detailed report and proposed patch.
I think your proposed fix isn't quite correct. I think the problem
lies in InitPartitionPruneContext() where we assume that the list
positions of step->exprs are in sync with the keyno. If you look at
perform_pruning_base_step() the code there makes a special effort to
skip over any keyno when a bit is set in opstep->nullkeys.
It seems that your patch is adjusting the keyno that's given to the
PruneCxtStateIdx() and it looks like (for your test case) it'll end up
passing keyno==0 when it should be passing keyno==1. keyno is the
index of the partition key, so you can't pass 0 when it's for key
index 1.
I wonder if it's worth expanding the tests further to cover more of
the pruning cases to cover run-time pruning too.
David
Attachment | Content-Type | Size |
---|---|---|
fix_runtime_pruning_keyno_idx.patch | application/octet-stream | 4.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2023-10-08 23:42:13 | Re: pg16: XX000: could not find pathkey item to sort |
Previous Message | Thomas Munro | 2023-10-08 23:19:30 | Re: CREATE DATABASE with filesystem cloning |