Hello. At Mon, 15 Jun 2026 13:52:36 +0530, Ashutosh Sharma <[email protected]> wrote in > Sorry for chiming in - I may well be misunderstanding this, but here's > how I'm currently thinking about it: > > Total transaction bytes refers to the size of decoded transactional > data accumulated in the reorder buffer for a given transaction. > > Sent bytes (as I understand from the patch) refers to the size of the > downstream output that the output plugin produces from that decoded > data, after any filtering and format conversion. > > To illustrate: if a transaction's decoded changes occupy 550 bytes in > the reorder buffer, but the output plugin filters some out and emits > only 300 bytes downstream, then total transaction bytes = 550 and sent > bytes = 300. Conversely, if all 550 bytes are converted into a more > verbose format and emitted as 700 bytes, total transaction bytes > remains 550 while sent bytes becomes 700. > > If I'm reading this right, since total bytes for a transaction is the > baseline from which transaction-derived downstream output is produced, > I wonder whether sent bytes should include only that > transaction-derived downstream output, or also downstream protocol > traffic such as keepalive messages, which are sent downstream but are > not derived from transaction bytes in the reorder buffer. > > My instinct is that if sent bytes are meant to measure > transaction-output throughput, keepalive messages probably shouldn't > be included, since they have no basis in transaction data and might > distort any comparison with total bytes. But I could be wrong - happy > to be corrected!
Thank you for the explanation. I think I understand the distinction you are making. However, my question is one step earlier than the keepalive-message question. I am wondering whether the new metric needs to be defined in terms of logical-change output in the first place. If I understand the use case correctly, I think the discussion here is primarily about relatively high-volume logical replication workloads. My point is that, in that situation, I would expect the amount of logical-change output and the amount of data actually sent over the replication connection to show broadly similar trends. The latter seems easier to interpret, while still providing a useful signal for monitoring and capacity-planning purposes. It also seems more intuitive, since it corresponds directly to the amount of data sent over the replication connection. Regards, -- Kyotaro Horiguchi NTT Open Source Software Center
