Re: Report bytes and transactions actually sent downtream

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: shveta malik <shveta(dot)malik(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Report bytes and transactions actually sent downtream
Date: 2025-09-24 13:13:10
Message-ID: aNPuZu7+oQfH4XUp@ip-10-97-1-34.eu-west-3.compute.internal
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
> <bertranddrouvot(dot)pg(at)gmail(dot)com> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2025-09-24 13:18:42 Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options
Previous Message Robert Haas 2025-09-24 12:27:47 Re: plan shape work