Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options
Date
Msg-id aKF8mPDqgQb3uBjG@paquier.xyz
Whole thread Raw
In response to Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options
Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options
List pgsql-hackers
On Sun, Aug 17, 2025 at 12:24:29AM +1200, David Rowley wrote:
> I noticed that the existing code has a set of global variables that
> keeps track of accesses, collisions and expansions for *all* tables in
> the backend. This didn't fit well with the single line elog. I kinda
> though the global information was a bit strange, so I just got rid of
> it. There was no "expansions" field to track the number of expansions
> for a single table, so I added one. I made all these uint64. I felt
> long (which can be 32-bit on some platforms) was too small for
> tracking the number of hash table accesses. Likely uint64 is too wide
> to track the expansions. That likely could be made smaller, but since
> these are not enabled by default, they're not taking up any struct
> space in normal builds.

-#ifdef HASH_STATISTICS
-static long hash_accesses,
-            hash_collisions,
-            hash_expansions;
-#endif

These global counters are as old as d31084e9d111.  Removing them
should not be a problem.

Using DEBUG4 looks sensible here for this purpose.

Side thing..  I'm wondering what prevents us from wiping out entirely
the use of long in this file.  long is 8 bytes everywhere, except on
WIN32 where it's 4 bytes (as you say), which is a bad practice as we
have been bitten by overflows because of this dependency in the patch.
Not related to this patch, still seems worth cleaning up while looking
at this code.  There are a few more things like HASHCTL, of course..
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Naga Appani
Date:
Subject: Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring
Next
From: Michael Paquier
Date:
Subject: Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options