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
