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

From David Rowley
Subject Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options
Date
Msg-id CAApHDvqJXnQvG8C6A83FiheVgJTWHEPUW39HXgcLyaY3G5fF9A@mail.gmail.com
Whole thread Raw
In response to Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options  (Michael Paquier <michael@paquier.xyz>)
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 Mon, 18 Aug 2025 at 17:06, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Mon, Aug 18, 2025 at 02:19:06PM +1200, David Rowley wrote:
> > On Mon, 18 Aug 2025 at 13:26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Yeah, it's really quite unclear what the existing HASH_DEBUG printout
> >> is good for.  At least in our usage, it doesn't tell you anything
> >> you can't discover from static code analysis.  I'm +1 for just
> >> dropping it altogether.
> >
> > I'm starting to lean more towards that myself. I had mostly just been
> > motivated to finding a way to prevent it from existing in a broken
> > state again.
>
> +1.

Ok. I've attached 2 patches. 0001 adjusted the HASH_STATISTICS output
to use DEBUG4 and 0002 removes HASH_DEBUG.

I've purposefully left references to HASH_DEBUG in the "Original
comments" section near the top of dynahash.c. That comment also
references function names that no longer exist.

> > HASH_STATISTICS I can imagine is more useful as that information isn't
> > otherwise recorded anywhere.
>
> By the way, once we have reached a conclusion here, I'll go update one
> of my animals to use what's remaining of the flags, so as this is
> captured in the future.

Sounds good. Thanks.

David

Attachment

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: GB18030-2022 Support in PostgreSQL
Next
From: Richard Guo
Date:
Subject: Re: Pathify RHS unique-ification for semijoin planning