On Wed, Apr 6, 2022 at 4:20 PM Amit Langote <amitlangot...@gmail.com> wrote: > And here is a version like that that passes make check-world. Maybe > still a WIP as I think comments could use more editing. > > Here's how the new implementation works: > > AcquireExecutorLocks() calls ExecutorDoInitialPruning(), which in turn > iterates over a list of PartitionPruneInfos in a given PlannedStmt > coming from a CachedPlan. For each PartitionPruneInfo, > ExecPartitionDoInitialPruning() is called, which sets up > PartitionPruneState and performs initial pruning steps present in the > PartitionPruneInfo. The resulting bitmapsets of valid subplans, one > for each PartitionPruneInfo, are collected in a list and added to a > result node called PartitionPruneResult. It represents the result of > performing initial pruning on all PartitionPruneInfos found in a plan. > A list of PartitionPruneResults is passed along with the PlannedStmt > to the executor, which is referenced when initializing > Append/MergeAppend nodes. > > PlannedStmt.minLockRelids defined by the planner contains the RT > indexes of all the entries in the range table minus those of the leaf > partitions whose subplans are subject to removal due to initial > pruning. AcquireExecutoLocks() adds back the RT indexes of only those > leaf partitions whose subplans survive ExecutorDoInitialPruning(). To > get the leaf partition RT indexes from the PartitionPruneInfo, a new > rti_map array is added to PartitionedRelPruneInfo. > > There's only one patch this time. Patches that added partitioned_rels > and plan_tree_walker() are no longer necessary.
Here's an updated version. In Particular, I removed part_prune_results list from PortalData, in favor of anything that needs to look at the list can instead get it from the CachedPlan (PortalData.cplan). This makes things better in 2 ways: * All the changes that were needed to produce the list to be pass to PortalDefineQuery() are now unnecessary (especially ugly ones were those made to pg_plan_queries()'s interface) * The cases in which the PartitionPruneResult being added to a QueryDesc can be assumed to be valid is more clearly define now; it's the cases where the portal's CachedPlan is also valid, that is, if the accompanying PlannedStmt is a cached one. -- Amit Langote EDB: http://www.enterprisedb.com
v12-0001-Optimize-AcquireExecutorLocks-to-skip-pruned-par.patch
Description: Binary data
