Re: Is 7.3 a good time to increase NAMEDATALEN ? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Is 7.3 a good time to increase NAMEDATALEN ?
Date
Msg-id 21969.1022003616@sss.pgh.pa.us
Whole thread Raw
In response to Is 7.3 a good time to increase NAMEDATALEN ?  ("Joel Burton" <joel@joelburton.com>)
List pgsql-hackers
"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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Per tuple overhead, cmin, cmax, OID
Next
From: Manuel Sugawara
Date:
Subject: Re: Redhat 7.3 time manipulation bug