pgsql: Fix partition pruning to treat stable comparison operators prope

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

pgsql: Fix partition pruning to treat stable comparison operators prope

Tom Lane-2
Fix partition pruning to treat stable comparison operators properly.

Cross-type comparison operators in a btree or hash opclass might be
only stable not immutable (this is true of timestamp vs. timestamptz
for example).  partprune.c ignored this possibility and would perform
plan-time pruning with them anyway, possibly leading to wrong answers
if the environment changed between planning and execution.

To fix, teach gen_partprune_steps() to do things differently when
creating plan-time pruning steps vs. run-time pruning steps.
analyze_partkey_exprs() also needs an extra check, which is rather
annoying but now is not the time to restructure things enough to
avoid that.

While at it, simplify the logic for the plan-time case a little
by insisting that the comparison value be a Const and nothing else.
This relies on the assumption that eval_const_expressions will have
reduced any immutable expression to a Const; which is not quite
100% true, but certainly any case that comes up often enough to be
interesting should have simplification logic there.

Also improve a bunch of inadequate/obsolete/wrong comments.

Per discussion of a report from Alan Jackson (though this fixes only one
aspect of that problem).  Back-patch to v11 where this code came in.

David Rowley, with some further hacking by me




Modified Files
src/backend/partitioning/partprune.c          | 191 ++++++++++++++++++++------
src/test/regress/expected/partition_prune.out |  88 ++++++++++++
src/test/regress/sql/partition_prune.sql      |  38 +++++
3 files changed, 272 insertions(+), 45 deletions(-)