Re: Change GUC hashtable to use simplehash?
От | Anton A. Melnikov |
---|---|
Тема | Re: Change GUC hashtable to use simplehash? |
Дата | |
Msg-id | 4c739718-27d6-44fe-9113-56a251c13275@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: Change GUC hashtable to use simplehash? (John Naylor <johncnaylorls@gmail.com>) |
Список | pgsql-hackers |
Hi! On 22.01.2025 11:37, John Naylor wrote: > On Fri, Jan 17, 2025 at 4:50 PM John Naylor <johncnaylorls@gmail.com> wrote: >> >> It would be a lot more readable to revert the offending commit >> instead, since its predecessor had a much simpler bytewise loop. Agreed that reverting seems as a preferable way, and here's why. I found that this valgrind error during initdb first appeared after 0aba25544. At the previous e97b672c88 where there is no error i did a small experiment on my laptop. With -O2 compilation from src/backend/catalog/namespace.с:369 that really executes inlined spcachekey_hash() to src/backend/catalog/namespace.с:369 123 asm instructions are executed when hashing the string "pg_catalog". In the master at 630f9a43 the spcachekey_hash() is not inlined and asm call <spcachekey_hash> executes 204 asm inctructions at the same conditions. HAVE__BUILTIN_CTZ is defined on my pc so finding the first non-zero rightmost bit requires the only asm command. With patch v2-0001-Add-valgrind-safe-code the same will take 216 asm instructions. Of cause, if the common average length of a hashed string is known, can be performed experiments that better correspond to reality. But, it seems to me, there shouldn't be any considerably large strings here, so the general trend is clear. Please correct me if I'm wrong. With the best regards, -- Anton A. Melnikov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: