Re: Is 7.3 a good time to increase NAMEDATALEN ?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Joel Burton" <joel(at)joelburton(dot)com>
Cc: "Pgsql-Hackers(at)Postgresql(dot) Org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Is 7.3 a good time to increase NAMEDATALEN ?
Date: 2002-05-21 17:53:36
Message-ID: 21969.1022003616@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Joel Burton" <joel(at)joelburton(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2002-05-21 18:54:06 Re: Redhat 7.3 time manipulation bug
Previous Message Tom Lane 2002-05-21 17:44:05 Re: Per tuple overhead, cmin, cmax, OID