Marginal hack to avoid spending a lot of time in find_join_rel during

large planning problems: when the list of join rels gets too long, make
an auxiliary hash table that hashes on the identifying Bitmapset.

1 files changed, 11 insertions, 1 deletions

diff --git a/src/include/nodes/relation.h b/src/include/nodes/relation.h
index 93dc78aece4..7c702f7105a 100644
--- a/src/include/nodes/relation.h
+++ b/src/include/nodes/relation.h
@@ -7,7 +7,7 @@
  * Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * $PostgreSQL: pgsql/src/include/nodes/relation.h,v 1.111 2005/06/06 04:13:36 tgl Exp $
+ * $PostgreSQL: pgsql/src/include/nodes/relation.h,v 1.112 2005/06/08 23:02:05 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -72,7 +72,17 @@ typedef struct PlannerInfo
 	struct RelOptInfo **base_rel_array;	/* All one-relation RelOptInfos */
 	int			base_rel_array_size;	/* current allocated array len */
 
+	/*
+	 * join_rel_list is a list of all join-relation RelOptInfos we have
+	 * considered in this planning run.  For small problems we just scan
+	 * the list to do lookups, but when there are many join relations we
+	 * build a hash table for faster lookups.  The hash table is present
+	 * and valid when join_rel_hash is not NULL.  Note that we still maintain
+	 * the list even when using the hash table for lookups; this simplifies
+	 * life for GEQO.
+	 */
 	List	   *join_rel_list;	/* list of join-relation RelOptInfos */
+	struct HTAB *join_rel_hash;	/* optional hashtable for join relations */
 
 	List	   *equi_key_list;	/* list of lists of equijoined
 								 * PathKeyItems */