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
