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
This commit is contained in:
Bruce Momjian 2002-02-25 04:06:52 +00:00
parent 7464e7f25a
commit f5dff44736
3 changed files with 8 additions and 26 deletions

View File

@ -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;

View File

@ -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

View File

@ -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 */