MIME-Version: 1.0
References: 
 <CAJDiXgi=Vcp1nh2UoZ5=7BCoR+uXoYzqMsfOfga-XxSUHjFj5Q@mail.gmail.com>
 <eok6kgntbec2vo35xp4eky5ef52ttb7trislyev63ty3ltu533@je4bpifl6spb>
 <CAJDiXgjPGu_cW9nsvciqdgAkqY5o5ugaxDvo3S-rOcqBPcHCPw@mail.gmail.com>
 <CAApHDvqA26O3mnRg=WgASdPrur7bybvGvLesHvnZ0cKQwoEuxA@mail.gmail.com>
 <CAJDiXggJkpxM_uqzwXj=c=q3w7JtShx8K24yeZqbkr_FHmVtUA@mail.gmail.com>
 <CAApHDvqbRe3K-YmqSPfXMxDY==wg9MhSGwKX_Pafw=-pw3w_bg@mail.gmail.com>
In-Reply-To: 
 <CAApHDvqbRe3K-YmqSPfXMxDY==wg9MhSGwKX_Pafw=-pw3w_bg@mail.gmail.com>
From: Daniil Davydov <3danissimo@gmail.com>
Date: Tue, 31 Mar 2026 21:49:59 +0700
Message-ID: 
 <CAJDiXgjK0EsCoKf_QeeWAne5an2rFmM7YKpQ1C3opVCmOCCSzw@mail.gmail.com>
Subject: Re: Get rid of redundant StringInfo accumulation
To: David Rowley <dgrowleyml@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
	Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAJDiXgjK0EsCoKf_QeeWAne5an2rFmM7YKpQ1C3opVCmOCCSzw%40mail.gmail.com>
Precedence: bulk

Hi,

On Tue, Mar 31, 2026 at 9:07=E2=80=AFPM David Rowley <dgrowleyml@gmail.com>=
 wrote:
>
> Do you mean that the new message_level_is_interesting() call isn't
> noticeable? Or that the extra work to build the StringInfo can't be
> noticed in an unpatched version?

I think that both message_level_is_interesting call and StringInfo building
are taking negligibly little time compared to the time of the entire reques=
t.
Of course I can create some synthetic test : huge loop with (for example)
KnownAssignedXidsDisplay call. This test IIUC will show that my patch makes
things better. But I guess this is not what you expect from me.

> If it's the latter, then what's the point?

TBH, I didn't notice that message_level_is_interesting is not considered fo=
r
the LOG level.. Anyway, I am still thinking about code consistency and poss=
ibly
noticeable changes related to lwlocks (see below).

> Your opening email seems to indicate that you noticed the issue from
> looking at the code. So, it appears that you didn't do this because
> you noticed that there was an actual measurable overhead and you saw a
> way to fix it. If that's the case then perhaps you've just assumed
> this will make a meaningful difference. If I've misunderstood that,
> please correct me and show us your test cases and the performance
> results.

You're precisely right. I noticed this issue from looking at the code (whil=
e
working on some other feature). So I do not have any benchmarks, which I th=
ink
can be created only for the changes in lock.c and proc.c (since there is a
lock acquired there). I will try to create such a benchmark. I hope it won'=
t
be as synthetic as I imagine it now.

Please note, that I don't have any information about the typical
log_lock_failures/log_lock_waits parameters configuration in a production.

--
Best regards,
Daniil Davydov