Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

On Sat, 16 Aug 2025 at 03:16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> * Neither printout identifies which hashtable it's talking about
> in any usable fashion, which is silly when we could print
> hashp->tabname.  HASH_DEBUG prints the pointer to the table,
> which is certainly useless unless you've got gdb attached to
> the session, and probably useless even then without the tabname.
>
> * The output formats are randomly inconsistent with each other,
> and don't look much like other outputs either.  I'm particularly
> vexed by the fact that you could not usefully grep the log for
> this data.  I think we should switch them to a single log line so
> that grepping for a hashtable name could produce something useful.
>
> * As it stands, HASH_DEBUG prints only at hashtable creation and
> HASH_STATISTICS prints only at table destruction.  Is that really
> enough? I'm thinking in particular of shared and session-lifespan
> hashtables, which won't ever receive a hash_destroy call.
>
> * One fairly believable use-case for hash_stats() is to be called
> manually from a debugger.  To make that a little easier, I think
> we should fix it to not crash if "where" is NULL.

I've attached another patch with all these things fixed up.

For the single line format, I made this use a similar format to how we
display various properties in text based EXPLAIN.

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.

This is from using the debugger:
2025-08-17 00:04:52.206 NZST [962296] DEBUG:  hash_stats:  Caller:
(unknown)  Table Name: "Relcache by OID"  Accesses: 194  Collisions:
23  Expansions: 0  Entries: 139  Key Size: 4  Max Bucket: 511  Segment
Count: 2

and some samples from the log:
2025-08-17 00:05:13.241 NZST [962325] DEBUG:  init_htab: Table Name:
"Relcache by OID"  Directory Size: 256  Segment Size: 256  Segment
Shift: 8  Max Bucket: 511  High Mask: 3ff  Low Mask: 1ff  Number
Segments: 2
2025-08-17 00:05:13.241 NZST [962325] DEBUG:  init_htab: Table Name:
"Portal hash"  Directory Size: 256  Segment Size: 256  Segment Shift:
8  Max Bucket: 15  High Mask: 1f  Low Mask: f  Number Segments: 1
2025-08-17 00:05:13.241 NZST [962325] DEBUG:  init_htab: Table Name:
"smgr relation table"  Directory Size: 256  Segment Size: 256  Segment
Shift: 8  Max Bucket: 511  High Mask: 3ff  Low Mask: 1ff  Number
Segments: 2
2025-08-17 00:05:13.243 NZST [962325] DEBUG:  init_htab: Table Name:
"Operator class cache"  Directory Size: 256  Segment Size: 256
Segment Shift: 8  Max Bucket: 63  High Mask: 7f  Low Mask: 3f  Number
Segments: 1

David