Horton

Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-18T05:06:19Z
Lists: pgsql-hackers 
On Mon, Aug 18, 2025 at 02:19:06PM +1200, David Rowley wrote:
> On Mon, 18 Aug 2025 at 13:26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah, it's really quite unclear what the existing HASH_DEBUG printout
>> is good for.  At least in our usage, it doesn't tell you anything
>> you can't discover from static code analysis.  I'm +1 for just
>> dropping it altogether.
> 
> I'm starting to lean more towards that myself. I had mostly just been
> motivated to finding a way to prevent it from existing in a broken
> state again.

+1.

> HASH_STATISTICS I can imagine is more useful as that information isn't
> otherwise recorded anywhere.

By the way, once we have reached a conclusion here, I'll go update one
of my animals to use what's remaining of the flags, so as this is
captured in the future.
--
Michael

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.