At Mon, 15 Jun 2026 09:48:51 +0530, Ashutosh Bapat <[email protected]> wrote in > 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/CAExHW5s6KntzUyUoMbKR5dgwRmd= > V2Ay_2%2BAnTgYGAzo%3DQv61wA%40mail.gmail.com
Thanks, that clarifies the use case. If the goal is to estimate the volume of data that downstream consumers such as Debezium need to process, I'm still not sure why this necessarily needs to be the amount of logical change data rather than the amount of data actually sent over the replication connection. For monitoring or capacity-planning purposes, wire bytes seem like they would provide a very similar signal. The protocol overhead is relatively small, especially when the traffic volume is high, and the definition is somewhat more straightforward since it corresponds directly to the amount of data transmitted downstream. Also, I'm not sure that the logical-change size is necessarily a more accurate representation of the amount of change being processed. Since the amount of logical change data is itself influenced by how the output plugin represents changes, it still seems somewhat dependent on representation, just in a different way. Could you explain a bit more about why the logical-change size is the important metric here, rather than the number of bytes actually sent? Regards, -- Kyotaro Horiguchi NTT Open Source Software Center
