Horton

Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: "'pgsql-hackers@lists.postgresql.org'" <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-15T03:42:23Z
Lists: pgsql-hackers 
"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com> writes:
>> There might be a case for removing HASH_STATISTICS too, but
>> it seems weaker.  I do recall having made use of that code
>> once years ago ...

> I have never used both options, but one point is that hash_stats() has been
> exported and extensions have called it. Is there a possibility that hidden
> developer is using?

Seems unlikely.  They couldn't count on it doing anything at all
in a standard build.  Moreover, even if HASH_STATISTICS is defined,
what it will do is print to stderr which is hardly a production-
friendly behavior.  So on the whole I'd bet lunch that no one
depends on hash_stats().

In any case, we'd be talking about a change in master only,
not something we'd back-patch.  So there would be time for
people to complain if anyone really cares.

> Anyway, I have no strong opinion. Attached patch does 1) remove HASH_DEBUG and
> 2) fix broken code with HASH_STATISTICS.

Whatever we do with this, let's do it in two separate patches,
just in case someone argues for reverting one or the other.
The issues don't seem to me to be fundamentally connected.

			regards, tom lane

Commits

  1. Remove HASH_DEBUG output from dynahash.c

  2. Use elog(DEBUG4) for dynahash.c statistics output

  3. Fix invalid format string in HASH_DEBUG code

  4. Fix failing -D HASH_STATISTICS builds

  5. Refactor initial hash lookup in dynahash.c

  6. Remove large fill factor support from dynahash.c.

  7. Remove broken and useless entry-count printing in HASH_DEBUG code.

  8. Partition the freelist for shared dynahash tables.