Hi,
On Tue, Mar 31, 2026 at 9:07 PM 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 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
