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