]> granicus.if.org Git - postgresql/commit
Rework code to determine partition pruning procedure
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Thu, 19 Apr 2018 14:22:31 +0000 (11:22 -0300)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Thu, 19 Apr 2018 15:01:37 +0000 (12:01 -0300)
commite5dcbb88a15d445e0ccb3db3194f4a122b792df6
tree41710d10773153d934bf729715089fb997f4eea7
parentcea5f9aa1244a6a803481f7e21a86e7e7037a9a5
Rework code to determine partition pruning procedure

Amit Langote reported that partition prune was unable to work with
arrays, enums, etc, which led him to research the appropriate way to
match query clauses to partition keys: instead of searching for an exact
match of the expression's type, it is better to rely on the fact that
the expression qual has already been resolved to a specific operator,
and that the partition key is linked to a specific operator family.
With that info, it's possible to figure out the strategy and comparison
function to use for the pruning clause in a manner that works reliably
for pseudo-types also.

Include new test cases that demonstrate pruning where pseudotypes are
involved.

Author: Amit Langote, Álvaro Herrera
Discussion: https://postgr.es/m/2b02f1e9-9812-9c41-972d-517bdc0f815d@lab.ntt.co.jp
src/backend/partitioning/partprune.c
src/test/regress/expected/partition_prune.out
src/test/regress/sql/partition_prune.sql