On Tue, Mar 17, 2026 at 12:12 PM Amit Kapila <[email protected]> wrote: > > > If yes, it makes sense to mention > > non-transactional messages separately in sent_bytes description. We > > can modify my previous suggestion as > > > > Amount of transaction changes and non-transactional messages sent > > downstream in the output plugin > > > > Isn't it better to use something on the lines of what Michael is > proposing in his last email [1]?
I missed his version in criss-cross emails. Copied here for completeness: "Amount of bytes decoded and sent downstream by the output plugin. This accounts for the output plugin filters, if any, and for the conversion into the output plugin format." Everywhere else, total_bytes, spill_bytes, we use the term "data" instead of "bytes". The "decoded" in the description of those two fields has a different meaning than what "decoded" means here. It's going to be confusing if we use the same term. I think we need to be consistent with other descriptions. But I agree with Michael's intent to make it less fancy. Following version covers it all Amount of transaction changes and non-transactional messages sent downstream in the output plugin format for this slot. The output plugin may filter the changes it receives. Hence the amount of data that it converts to the output plugin format is less than the <structfield>total_bytes</structfield>. But the format of data before and after the conversion is different. Hence the value of <structfield>sent_bytes</structfield> is not directly related to the value of <structfield>total_bytes</structfield>. It tells what exactly is counted. It's less fancy (though a bit verbose). Once we add non-transactional messages part to total_bytes, both the descriptions will be consistent. It also explains why sent_bytes and total_bytes can not be compared. Since streamed_bytes and spilled_bytes never contain non-transactional messages, we don't need to modify those descriptions. What do you think? -- Best Wishes, Ashutosh Bapat
