Improve performance of partition pruning remapping a little

Enterprise / PostgreSQL - Tom Lane [sss.pgh.pa.us] - 15 November 2018 18:34 EST

ExecFindInitialMatchingSubPlans has to update the PartitionPruneState's subplan mapping data to account for the removal of subplans it prunes. However, that's only necessary if run-time pruning will also occur, so we can skip it when that won't happen, which should result in not needing to do the remapping in many cases. (We now need it only when some partitions are potentially startup-time prunable and others are potentially run-time prunable, which seems like an unusual case.)

Also make some marginal performance improvements in the remapping itself. These will mainly win if most partitions got pruned by the startup-time pruning, which is perhaps a debatable assumption in this context.

Also fix some bogus comments, and rearrange code to marginally reduce space consumption in the executor's query-lifespan context.

David Rowley, reviewed by Yoshikazu Imai

Discussion: https://postgr.es/m/CAKJS1f9+m6-di-zyy4B4AGn0y1B9F8UKDRigtBbNviXOkuyOpw@mail.gmail.com

34c9e455d0 Improve performance of partition pruning remapping a little.
src/backend/executor/execPartition.c | 99 ++++++++++++++++-----------
src/test/regress/expected/partition_prune.out | 50 ++++++++++++++
src/test/regress/sql/partition_prune.sql | 28 ++++++++
3 files changed, 138 insertions(+), 39 deletions(-)

Upstream: git.postgresql.org


  • Share