On 2020-Sep-04, Jakub Wartak wrote: > After removing HASH_FFACTOR PostgreSQL still compiles... Would > removing it break some external API/extensions ?
FWIW, HASH_FFACTOR has *never* been used in Postgres core code. https://postgr.es/m/20160418180711.55ac82c0@fujitsu already reported that this flag was unused a few years ago. And a search through codesearch.debian.net shows that no software packaged by Debian uses that flag either. *If* any third-party extension is using HASH_FFACTOR, it can easily be unbroken by removing the flag or #defining it to zero; the removal would only be a problem if anyone showed that there is a performance loss by using the default fillfactor for some dynahash table instead of their custom value. I think if we know that there's a 4% performance increase by removing the division that comes with an ability to use a custom fillfactor that nobody uses or has ever used, it makes sense to remove that ability. ... however, if we're really tense about improving some hash table's performance, it might be worth trying to use simplehash.h instead of dynahash.c for it. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services