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 по дате отправления: