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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
