Hi, On Wed, Sep 24, 2025 at 03:37:07PM +0530, Ashutosh Bapat wrote: > On Wed, Sep 24, 2025 at 1:55 PM Bertrand Drouvot > <[email protected]> wrote: > > Right. But, in the example above, do you consider "skip-empty-xacts" as > > "core" > > or "plugin" filtering? > > > > It's an option part of the "test_decoding" plugin, so it's the plugin > > choice to > > not display empty xacts (should the option be set accordingly). Then should > > it > > be reported in plugin_filtered_bytes? (one could write a plugin, decide to > > skip/filter empty xacts or whatever in the plugin callbacks: should that be > > reported as plugin_filtered_bytes?) > > If a transaction becomes empty because the plugin filtered all the > changes then plugin_filtered_bytes will be incremented by the amount > of filtered changes. If the transaction was empty because core didn't > send any of the changes to the output plugin, there was nothing > filtered by the output plugin so plugin_filtered_bytes will not be > affected. > > skip_empty_xacts controls whether BEGIN and COMMIT are sent for an > empty transaction or not. It does not filter "changes". It affects > "sent_bytes".
skip_empty_xacts was just an example. I mean a plugin could decide to filter all the inserts for example (not saying it makes sense). But I think we'are saying the same: say a plugin wants to filter the inserts then it's its responsability to increment ctx->stats->filteredBytes in its "change_cb" callback for the REORDER_BUFFER_CHANGE_INSERT action, right? If so, I wonder if it would make sense to provide an example in the test_decoding plugin (I can see it's done for pgoutput but that might sound more natural to look in contrib if one is searching for an example). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
