Re: [PATCH] Present all committed transaction to the output plugin

Hi,

On 2021-02-20 13:48:49 +0100, Markus Wanner wrote:
> However, that's not what the patch changes. It just moves the decision to
> the output plugin, giving it more flexibility. And possibly allowing it to
> still take action.

It's not free though - there's plenty workloads where there's an xid but
no other WAL records for transactions. Threading those through the
output plugin does increase the runtime cost. And because such
transactions will typically not incur a high cost on the primary
(e.g. in case of unlogged tables, there'll be a commit record, but often
the transaction will not wait for the commit record to be flushed to
disk), increasing the replication overhead isn't great.

> For example, in case of a distributed two-phase commit
> scenario, where the publisher waits after its local PREPARE for replicas to
> also PREPARE.

Why is that ever interesting to do in the case of empty transactions?
Due to the cost of doing remote PREPAREs ISTM you'd always want to
implement the optimization of not doing so for empty transactions.

> So I'm rather wondering: what's the use case of filtering some, but
> not all empty transactions (on the decoder side)?

I'm wondering the opposite: What's a potential use case for handing
"trivially empty" transactions to the output plugin that's worth
incurring some cost for everyone?

Greetings,

Andres Freund