Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

On Sat, 16 Aug 2025 at 03:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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