I've attached a simple patch which should improve the performance of

hashname() and reduce the penalty incured when NAMEDATALEN is increased.
I posted this to -hackers a couple days ago, and there haven't been any
major complaints. It passes the regression tests. See -hackers for more
discussion, as well as the suggestion from Tom Lane on which this patch
is based.

Unless anyone sees any problems, please apply for 7.3.

Cheers,

Neil Conway

src/backend/access/hash/hashfunc.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/access/hash/hashfunc.c,v 1.30 2001/03/22 03:59:13 momjian Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/access/hash/hashfunc.c,v 1.31 2002/02/25 04:06:47 momjian Exp $
  *
  * NOTES
  *	  These functions are stored in pg_amproc.	For each operator class
@@ -95,7 +95,7 @@ hashname(PG_FUNCTION_ARGS)
 {
 	char	   *key = NameStr(*PG_GETARG_NAME(0));
 
-	return hash_any((char *) key, NAMEDATALEN);
+	return hash_any(key, strlen(key));
 }
 
 /*
@@ -125,7 +125,7 @@ hashvarlena(PG_FUNCTION_ARGS)
  *
  * (Comment from the original db3 hashing code: )
  *
- * "This is INCREDIBLY ugly, but fast.  We break the string up into 8 byte
+ * This is INCREDIBLY ugly, but fast.  We break the string up into 8 byte
  * units.  On the first time through the loop we get the 'leftover bytes'
  * (strlen % 8).  On every later iteration, we perform 8 HASHC's so we handle
  * all 8 bytes.  Essentially, this saves us 7 cmp & branch instructions.  If
@@ -134,7 +134,7 @@ hashvarlena(PG_FUNCTION_ARGS)
  * "OZ's original sdbm hash"
  */
 Datum
-hash_any(char *keydata, int keylen)
+hash_any(const char *keydata, int keylen)
 {
 	uint32		n;
 	int			loop;

src/backend/utils/cache/catcache.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/utils/cache/catcache.c,v 1.87 2002/02/19 20:11:17 tgl Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/utils/cache/catcache.c,v 1.88 2002/02/25 04:06:50 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -97,7 +97,6 @@ static Index CatalogCacheComputeHashIndex(CatCache *cache,
 static Index CatalogCacheComputeTupleHashIndex(CatCache *cache,
 								  HeapTuple tuple);
 static void CatalogCacheInitializeCache(CatCache *cache);
-static Datum cc_hashname(PG_FUNCTION_ARGS);
 #ifdef CATCACHE_STATS
 static void CatCachePrintStats(void);
 #endif
@@ -116,7 +115,7 @@ GetCCHashFunc(Oid keytype)
 		case CHAROID:
 			return hashchar;
 		case NAMEOID:
-			return cc_hashname;
+			return hashname;
 		case INT2OID:
 			return hashint2;
 		case INT2VECTOROID:
@@ -137,23 +136,6 @@ GetCCHashFunc(Oid keytype)
 	}
 }
 
-static Datum
-cc_hashname(PG_FUNCTION_ARGS)
-{
-	/*
-	 * We need our own variant of hashname because we want to accept
-	 * null-terminated C strings as search values for name fields. So, we
-	 * have to make sure the data is correctly padded before we compute
-	 * the hash value.
-	 */
-	NameData	my_n;
-
-	namestrcpy(&my_n, NameStr(*PG_GETARG_NAME(0)));
-
-	return DirectFunctionCall1(hashname, NameGetDatum(&my_n));
-}
-
-
 #ifdef CATCACHE_STATS
 
 static void

src/include/access/hash.h

@@ -7,7 +7,7 @@
  * Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * $Id: hash.h,v 1.42 2001/11/05 17:46:31 momjian Exp $
+ * $Id: hash.h,v 1.43 2002/02/25 04:06:52 momjian Exp $
  *
  * NOTES
  *		modeled after Margo Seltzer's hash implementation for unix.
@@ -265,7 +265,7 @@ extern Datum hashoidvector(PG_FUNCTION_ARGS);
 extern Datum hashint2vector(PG_FUNCTION_ARGS);
 extern Datum hashname(PG_FUNCTION_ARGS);
 extern Datum hashvarlena(PG_FUNCTION_ARGS);
-extern Datum hash_any(char *keydata, int keylen);
+extern Datum hash_any(const char *keydata, int keylen);
 
 
 /* private routines */