public inbox for [email protected]  

help / color / mirror / Atom feed
From: Daniil Davydov <[email protected]>
To: David Rowley <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Postgres hackers <[email protected]>
Subject: Re: Get rid of redundant StringInfo accumulation
Date: Tue, 31 Mar 2026 21:49:59 +0700
Message-ID: <CAJDiXgjK0EsCoKf_QeeWAne5an2rFmM7YKpQ1C3opVCmOCCSzw@mail.gmail.com> (raw)
In-Reply-To: <CAApHDvqbRe3K-YmqSPfXMxDY==wg9MhSGwKX_Pafw=-pw3w_bg@mail.gmail.com>
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>

Hi,

On Tue, Mar 31, 2026 at 9:07 PM David Rowley <[email protected]> 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 request.
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 for
the LOG level.. Anyway, I am still thinking about code consistency and possibly
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 (while
working on some other feature). So I do not have any benchmarks, which I think
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





view thread (9+ messages)

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Get rid of redundant StringInfo accumulation
  In-Reply-To: <CAJDiXgjK0EsCoKf_QeeWAne5an2rFmM7YKpQ1C3opVCmOCCSzw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox