Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

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