]> granicus.if.org Git - postgresql/commit
Apply constraint exclusion more generally in partitioning
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Wed, 7 Aug 2019 16:21:22 +0000 (12:21 -0400)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Wed, 7 Aug 2019 16:21:54 +0000 (12:21 -0400)
commit4e85642d935eb13341584df7776eb76585d45819
treeac0e651b9ccb07e955c62f305d58c7a1e32faf3e
parent1f33f211bc531d257f84fefb9208dd43e8718972
Apply constraint exclusion more generally in partitioning

We were applying constraint exclusion on the partition constraint when
generating pruning steps for a clause, but only for the rather
restricted situation of them being boolean OR operators; however it is
possible to have differently shaped clauses that also benefit from
constraint exclusion.  This applies particularly to the default
partition since their constraints are in essence a long list of OR'ed
subclauses ... but it applies to other cases too.  So in certain cases
we're scanning partitions that we don't need to.

Remove the specialized code in OR clauses, and add a generally
applicable test of the clause refuting the partition constraint; mark
the whole pruning operation as contradictory if it hits.

This has the unwanted side-effect of testing some (most? all?)
constraints more than once if constraint_exclusion=on.  That seems
unavoidable as far as I can tell without some additional work, but
that's not the recommended setting for that parameter anyway.
However, because this imposes additional processing cost for all
queries using partitioned tables, I decided not to backpatch this
change.

Author: Amit Langote, Yuzuko Hosoya, Álvaro Herrera
Reviewers: Shawn Wang, Thibaut Madeleine, Yoshikazu Imai, Kyotaro
Horiguchi; they were also uncredited reviewers for commit 489247b0e615.
Discussion: https://postgr.es/m/9bb31dfe-b0d0-53f3-3ea6-e64b811424cf@lab.ntt.co.jp
src/backend/partitioning/partprune.c
src/test/regress/expected/partition_prune.out
src/test/regress/sql/partition_prune.sql