Re: Get rid of redundant StringInfo accumulation - Mailing list pgsql-hackers

From David Rowley
Subject Re: Get rid of redundant StringInfo accumulation
Date
Msg-id CAApHDvqA26O3mnRg=WgASdPrur7bybvGvLesHvnZ0cKQwoEuxA@mail.gmail.com
Whole thread
In response to Re: Get rid of redundant StringInfo accumulation  (Daniil Davydov <3danissimo@gmail.com>)
Responses Re: Get rid of redundant StringInfo accumulation
List pgsql-hackers
On Tue, 31 Mar 2026 at 03:24, Daniil Davydov <3danissimo@gmail.com> wrote:
> Am I missing something?

I have an opinion here too. It's similar to Andres', and I expect you
won't like it:

Looking at the other users of message_level_is_interesting(), every
one of them that's passing a const is using one of the DEBUG levels,
in which case the vast majority of the time we will take the
short-circuit path. All of the direct cases you're adding pass LOG.
Indirectly, I see some DEBUG3s being passed via
KnownAssignedXidsDisplay(), so maybe that's worth it. I don't know.
You've offered us nothing in terms of performance results from patched
vs unpatched. For me, when I see that, I just assume the person wrote
the patch because they can, not because they thought it was a good
idea. Since this place is rife with people using things like static
analysers and AI tools to give them patch ideas, and since those tools
have about zero context as to if the patch is a good idea or not, it's
very much not inspiring to commit any patch that comes with no proof
that it does what it's meant to do, especially one that has a
trade-off that is disadvantageous to people running the standard
logging levels.

If you still think this is a good idea, then you're going to need to
show benchmark results and scripts to prove that the extra overhead of
message_level_is_interesting() is low enough and the advantages of
skipping the extra StringInfo code is good enough to warrant doing
this. If you don't think that's worth your time, then why do you think
it's worth someone else's? It's your patch.

David



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Refactor query normalization into core query jumbling
Next
From: Jacob Champion
Date:
Subject: Re: Custom oauth validator options