On Sat, 16 Aug 2025 at 03:16, Tom Lane <t...@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
hash_debug_v2.patch
Description: Binary data
