Fix performance problems with pg_index lookups (see, for example,

discussion of 5/19/00).  pg_index is now searched for indexes of a
relation using an indexscan.  Moreover, this is done once and cached
in the relcache entry for the relation, in the form of a list of OIDs
for the indexes.  This list is used by the parser and executor to drive
lookups in the pg_index syscache when they want to know the properties
of the indexes.  Net result: index information will be fully cached
for repetitive operations such as inserts.

1 files changed, 8 insertions, 1 deletions

diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c
index 31c96c7d6ab..f0d61aa1123 100644
--- a/src/backend/commands/indexcmds.c
+++ b/src/backend/commands/indexcmds.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/commands/indexcmds.c,v 1.29 2000/06/15 03:32:07 momjian Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/commands/indexcmds.c,v 1.30 2000/06/17 21:48:42 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -221,6 +221,13 @@ DefineIndex(char *heapRelationName,
 					 lossy, unique, primary);
 	}
 
+	/*
+	 * We update the relation's pg_class tuple even if it already has
+	 * relhasindex = true.  This is needed to cause a shared-cache-inval
+	 * message to be sent for the pg_class tuple, which will cause other
+	 * backends to flush their relcache entries and in particular their
+	 * cached lists of the indexes for this relation.
+	 */
 	setRelhasindexInplace(relationId, true, false);
 }