Fix partition pruning to treat stable comparison operators properly

Enterprise / PostgreSQL - Tom Lane [] - 16 May 2019 15:58 EDT

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


4b1fcb43d0 Fix partition pruning to treat stable comparison operators properly.
src/backend/partitioning/partprune.c | 203 +++++++++++++++++++-------
src/test/regress/expected/partition_prune.out | 87 +++++++++++
src/test/regress/sql/partition_prune.sql | 38 +++++
3 files changed, 278 insertions(+), 50 deletions(-)


  • Share