Skip site navigation (1) Skip section navigation (2)

Re: Bug #652: NAMEDATALEN limitations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Bug #652: NAMEDATALEN limitations
Date: 2002-04-30 20:04:33
Message-ID: 21990.1020197073@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-sql
I said:
> One possible theory is that if NAMEDATALEN isn't a multiple of
> sizeof(int), the compiler's idea of sizeof(NameData) will probably be
> NAMEDATALEN rounded up to the next multiple of sizeof(int).

For the record, this does indeed seem to be the root cause for Erik's
complaint.  relcache.c declares the key size for its relation name
cache index as sizeof(NameData) --- so if that's larger than NAMEDATALEN
the hashtable code will end up trying to compare pad bytes that
probably haven't been zeroed out.

It looks to me like it would not really be practical to expect the
system to work when sizeof(NameData) is different from NAMEDATALEN;
we could maybe eliminate the existing discrepancies but more would
surely creep in.  So I've added comments to document that NAMEDATALEN
must be a multiple of sizeof(int).

BTW, I suspect that Names used as hashtable keys may explain the
residual speed differences that people have been reporting for large
values of NAMEDATALEN.  The dynahash.c code assumes fixed-length keys
and will compare all bytes out to the specified length, no matter what
--- so the extra cycles may all be spent in key comparisons for
dynahash tables.  Perhaps this could be fixed.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Jean-Luc LachanceDate: 2002-04-30 20:34:36
Subject: performance on update table from a join
Previous:From: Tom LaneDate: 2002-04-30 18:45:53
Subject: Re: Bug #652: NAMEDATALEN limitations

pgsql-sql by date

Next:From: Jean-Luc LachanceDate: 2002-04-30 20:34:36
Subject: performance on update table from a join
Previous:From: Tom LaneDate: 2002-04-30 18:45:53
Subject: Re: Bug #652: NAMEDATALEN limitations

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group