Re: Report bytes and transactions actually sent downtream

Hi,

On 2025-12-11 10:29:42 +0530, Ashutosh Bapat wrote:
> Please review.

I'd simplify the patch to, initially, to just track the sent bytes. For one,
that's by *far* the most useful statistic. But I also have some concerns
about the other stats:

- To me filteredBytes is a pretty bogus number - the size that the output
plugin would have sent and ReorderBufferChangeSize() are only kinda
related. It'll be a hard number to interpret, I think.

It also seems to not account for filtering that happens based on the origin
id.

- I don't have fundamental opposition to tracking the number of sent
transactions, but I think the implementation is at the wrong place.

I think we ought to add explicit support for output plugins to filter
transactions. Calling output plugins once for each change in a large
transaction, which we already decided to not send out, makes no sense. It's
far from free to do all the setup to decode a tuple, if the transaction is
filtered, we shouldn't do that.

It's also far far from free to restore changes from disk if we are going to
throw away the whole transaction.

The current way requires each output plugin to maintain its own tracking
about whether it decided to not output the transaction, which doesn't seem
right to me.

I'm also just not sure how useful it is, because most of the time we're
going to filter on a per-change basis (e.g. only rels in a publication). But
that's only sometimes going to affect the numbers of sent transactions.

I'm not convinced as-is it's worth the breakage of all output plugins.

Greetings,

Andres