From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | Bertrand Drouvot <bertranddrouvot(dot)pg(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-25 04:23:05 |
Message-ID: | CAExHW5vYVZJbTjmunzaSBO-ed0qDWW+OSFH7-qi8zBYrWvj8OQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 24, 2025 at 6:43 PM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>
> 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?
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).
test_decoding does not make use of publication at all. Publication
controls filtering and so test_decoding does not have any examples of
filtering code. Doesn't make sense to add code to manipulate
filteredBytes there.
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-09-25 04:35:07 | Re: Orphan page in _bt_split |
Previous Message | Richard Guo | 2025-09-25 04:23:00 | Re: Eager aggregation, take 3 |