On Fri, Jun 12, 2026 at 12:32 PM Kyotaro Horiguchi <[email protected]> wrote: > > Let me go back to the original motivation. > > As I understand it, the problem was that, among several subscribers > connected through different slots, one slot was lagging behind. The > total_txns and total_bytes values for that slot appeared smaller, and > you wanted to know where the bottleneck was. > > I wonder if part of the confusion comes from the fact that it is not > yet clear what conclusions a user is expected to draw from these new > values. > > What I am still not quite sure about is how the proposed sent_bytes > value would be used to make that distinction. It sounds like the idea > is not necessarily to look at its rate over time, but perhaps to > compare total_bytes with the proposed sent_bytes. However, as has > been discussed, these two values seem to measure different things, so > I am not sure that such a comparison would be straightforward. > > I think it would help move the discussion forward if you could explain > more concretely how these new values would be used to identify the > bottleneck in the case you described.
As I have explained in [1], total_bytes indicates the amount of data added to the reorder buffer. It does not indicate the amount of data in logical form sent downstream. The system which triggered this issue used Debezium as the downstream. The customer wanted to configure Debezium so that it can consume the logical changes in real time. But they had no clue about the amount of logical changes they received from upstream. total_bytes does not help since it's the amount of WAL added to reorder buffer; not the amount of logical changes sent downstream. Hence proposal to add new column sent_bytes. I hope this helps. [1] https://www.postgresql.org/message-id/flat/CAExHW5s6KntzUyUoMbKR5dgwRmdV2Ay_2%2BAnTgYGAzo%3DQv61wA%40mail.gmail.com -- Best Wishes, Ashutosh Bapat
