Thread: Is 7.3 a good time to increase NAMEDATALEN ?
Noticed that increasing NAMEDATALEN to 128 is still on the TODO. Given that the addition of namespaces for 7.3 is going to require many client utilities to be updated anyway, is this a reaonable time to bring this increase into the standard distribution? It seems like it would be minor pain whenever we do this, and 7.3 could be as good a time as any. - J. Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton Knowledge Management & Technology Consultant
"Joel Burton" <joel@joelburton.com> writes:
> Noticed that increasing NAMEDATALEN to 128 is still on the TODO.
> Given that the addition of namespaces for 7.3 is going to require many
> client utilities to be updated anyway, is this a reaonable time to bring
> this increase into the standard distribution?
Right at the moment we are still trying to understand/eliminate the
performance penalty from increasing NAMEDATALEN. At last report
someone had measured it as still being annoying large on pgbench.
I have not done any profiling but my best theory at the moment is that
the remaining cost must be in lookup key matching for in-memory hash
tables. dynahash.c treats keys as fixed-length and always does a
memcmp(), which is going to get slower with bigger NAMEDATALEN, even
if the actually used names aren't getting longer.
The issue might be fixable by teaching this code to use strcmp() for
Name keys, but I haven't tried.
regards, tom lane
On Tue, 21 May 2002 11:41:26 -0400 "Joel Burton" <joel@joelburton.com> wrote: > Noticed that increasing NAMEDATALEN to 128 is still on the TODO. The last benchmarks I saw indicate that there's still a significant performance hit when increasing NAMEDATALEN, whether to 64 or 128. Given that only a small percentage of PostgreSQL users need long identifiers, and *everyone* would suffer the performance hit, I'd rather that we not touch NAMEDATALEN until more work has been done on attempting to reduce the performance penalty. Until then, the people who absolutely, positively must have long identifiers can just raise NAMEDATALEN themselves. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
> -----Original Message----- > From: Neil Conway [mailto:nconway@klamath.dyndns.org] > Sent: Tuesday, May 21, 2002 12:19 PM > To: Joel Burton > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Is 7.3 a good time to increase NAMEDATALEN ? > > > On Tue, 21 May 2002 11:41:26 -0400 > "Joel Burton" <joel@joelburton.com> wrote: > > Noticed that increasing NAMEDATALEN to 128 is still on the TODO. > > The last benchmarks I saw indicate that there's still a significant > performance hit when increasing NAMEDATALEN, whether to 64 or 128. > > Given that only a small percentage of PostgreSQL users need long > identifiers, and *everyone* would suffer the performance hit, I'd > rather that we not touch NAMEDATALEN until more work has been > done on attempting to reduce the performance penalty. > > Until then, the people who absolutely, positively must have long > identifiers can just raise NAMEDATALEN themselves. I'm sure that this is an idiotic thing to say, but why not just make it varchar? Most of the time the database objects will be small (maybe 10 characters on average) but sometimes you want them to be really large.
"Dann Corbit" <DCorbit@connx.com> writes:
> I'm sure that this is an idiotic thing to say, but why not just make it
> varchar?
The main reason NAME is a fixed-length datatype is that we'd have to
rewrite (and make slower) a lot of catalog-accessing code that expects
to be able to access other fields in catalog tuples at fixed offsets.
I do not think it's worth it.
Also, the existing performance bottlenecks look to me to be associated
with assumptions that NAME is fixed-length. To convert to varlena NAME,
we'd still have to fix all that code.
regards, tom lane