Re: Report bytes and transactions actually sent downtream

Hi,

On Fri, Jun 12, 2026 at 12:32 PM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> 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.
>

Regarding the use case of this new metric, this is my understanding,
although Ashutosh Bapat would be in a better position to comment on
its intended value and use cases. I'll wait for his perspective as
well.

My understanding is as follows:

During logical decoding, ReorderBufferProcessTXN() iterates through
the decoded changes belonging to a top-level transaction and its
subtransactions in LSN order, invoking the output plugin callbacks for
each change. For large transactions, it may be useful to expose
progress while this processing is still in progress. For example, the
system could track logical changes as they are processed and sent
downstream, periodically publishing progress to shared memory so that
users can understand how far the walsender has progressed through a
large transaction.

By contrast, total_bytes is essentially an end-of-transaction metric.
It becomes available only after processing has completed and therefore
does not provide visibility into the walsender's progress while a
large transaction is actively being decoded and streamed.

--
With Regards,
Ashutosh Sharma.