database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-09 06:21:09 +03:00
Code Activity

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

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files

8
src/backend/access/hash/hashfunc.c
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;