aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/execUtils.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-10-04 14:03:37 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2018-10-04 14:03:42 -0400
commit9ddef36278a9f676c07d0b4d9f33fa22e48ce3b5 (patch)
treeec564a5f9c1cd536a6af60a0971bf7e9900ae36c /src/backend/executor/execUtils.c
parentfb9e93a2c5cf99e59a7e9362afd462f29e71bc1e (diff)
downloadpostgresql-9ddef36278a9f676c07d0b4d9f33fa22e48ce3b5.tar.gz
postgresql-9ddef36278a9f676c07d0b4d9f33fa22e48ce3b5.zip
Centralize executor's opening/closing of Relations for rangetable entries.
Create an array estate->es_relations[] paralleling the es_range_table, and store references to Relations (relcache entries) there, so that any given RT entry is opened and closed just once per executor run. Scan nodes typically still call ExecOpenScanRelation, but ExecCloseScanRelation is no more; relation closing is now done centrally in ExecEndPlan. This is slightly more complex than one would expect because of the interactions with relcache references held in ResultRelInfo nodes. The general convention is now that ResultRelInfo->ri_RelationDesc does not represent a separate relcache reference and so does not need to be explicitly closed; but there is an exception for ResultRelInfos in the es_trig_target_relations list, which are manufactured by ExecGetTriggerResultRel and have to be cleaned up by ExecCleanUpTriggerState. (That much was true all along, but these ResultRelInfos are now more different from others than they used to be.) To allow the partition pruning logic to make use of es_relations[] rather than having its own relcache references, adjust PartitionedRelPruneInfo to store an RT index rather than a relation OID. Amit Langote, reviewed by David Rowley and Jesper Pedersen, some mods by me Discussion: https://postgr.es/m/468c85d9-540e-66a2-1dde-fec2b741e688@lab.ntt.co.jp
Diffstat (limited to 'src/backend/executor/execUtils.c')
-rw-r--r--src/backend/executor/execUtils.c60
1 files changed, 36 insertions, 24 deletions
diff --git a/src/backend/executor/execUtils.c b/src/backend/executor/execUtils.c
index ba93b401046..a89ef2a482f 100644
--- a/src/backend/executor/execUtils.c
+++ b/src/backend/executor/execUtils.c
@@ -25,7 +25,8 @@
* etc
*
* ExecOpenScanRelation Common code for scan node init routines.
- * ExecCloseScanRelation
+ *
+ * ExecGetRangeTableRelation Fetch Relation for a rangetable entry.
*
* executor_errposition Report syntactic position of an error.
*
@@ -107,6 +108,7 @@ CreateExecutorState(void)
estate->es_snapshot = InvalidSnapshot; /* caller must initialize this */
estate->es_crosscheck_snapshot = InvalidSnapshot; /* no crosscheck */
estate->es_range_table = NIL;
+ estate->es_relations = NULL;
estate->es_plannedstmt = NULL;
estate->es_junkFilter = NULL;
@@ -648,15 +650,9 @@ Relation
ExecOpenScanRelation(EState *estate, Index scanrelid, int eflags)
{
Relation rel;
- Oid reloid;
- /* Open the relation and verify lock was obtained upstream */
- reloid = getrelid(scanrelid, estate->es_range_table);
- rel = heap_open(reloid, NoLock);
- Assert(IsParallelWorker() ||
- CheckRelationLockedByMe(rel,
- rt_fetch(scanrelid, estate->es_range_table)->rellockmode,
- true));
+ /* Open the relation. */
+ rel = ExecGetRangeTableRelation(estate, scanrelid);
/*
* Complain if we're attempting a scan of an unscannable relation, except
@@ -674,24 +670,40 @@ ExecOpenScanRelation(EState *estate, Index scanrelid, int eflags)
return rel;
}
-/* ----------------------------------------------------------------
- * ExecCloseScanRelation
- *
- * Close the heap relation scanned by a base-level scan plan node.
- * This should be called during the node's ExecEnd routine.
- *
- * Currently, we do not release the lock acquired by ExecOpenScanRelation.
- * This lock should be held till end of transaction. (There is a faction
- * that considers this too much locking, however.)
+/*
+ * ExecGetRangeTableRelation
+ * Open the Relation for a range table entry, if not already done
*
- * If we did want to release the lock, we'd have to repeat the logic in
- * ExecOpenScanRelation in order to figure out what to release.
- * ----------------------------------------------------------------
+ * The Relations will be closed again in ExecEndPlan().
*/
-void
-ExecCloseScanRelation(Relation scanrel)
+Relation
+ExecGetRangeTableRelation(EState *estate, Index rti)
{
- heap_close(scanrel, NoLock);
+ Relation rel;
+
+ Assert(rti > 0 && rti <= list_length(estate->es_range_table));
+
+ rel = estate->es_relations[rti - 1];
+ if (rel == NULL)
+ {
+ /* First time through, so open the relation */
+ RangeTblEntry *rte = rt_fetch(rti, estate->es_range_table);
+
+ Assert(rte->rtekind == RTE_RELATION);
+
+ rel = estate->es_relations[rti - 1] = heap_open(rte->relid, NoLock);
+
+ /*
+ * Verify that appropriate lock was obtained before execution.
+ *
+ * In the case of parallel query, only the leader would've obtained
+ * the lock (that needs to be fixed, though).
+ */
+ Assert(IsParallelWorker() ||
+ CheckRelationLockedByMe(rel, rte->rellockmode, false));
+ }
+
+ return rel;
}
/*