Re: Is 7.3 a good time to increase NAMEDATALEN ?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Is 7.3 a good time to increase NAMEDATALEN ?
Дата
Msg-id 21969.1022003616@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Is 7.3 a good time to increase NAMEDATALEN ?  ("Joel Burton" <joel@joelburton.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Per tuple overhead, cmin, cmax, OID
Следующее
От: Manuel Sugawara
Дата:
Сообщение: Re: Redhat 7.3 time manipulation bug