Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding

On Fri, Feb 21, 2025 at 7:57 AM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
>
> On Fri, Feb 21, 2025 at 12:57 PM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
> >
> > Conclusion:
> > The patched code with 100 transaction throttling significantly
> > improves performance, reducing execution time by ~69% when no
> > published transactions are involved, ~43% with partial published
> > transactions, and ~15% in all published transactions.
> > Attaching a graph showing the performance differences.
> >
>
> In these tests, I also see an increased performance with the patch
> even when all transactions are published. I will investigate why this
> happens and update.
>

Yes, it is important to investigate this because in the best case, it
should match with HEAD. One thing you can verify is whether the
changes processed on the server are exactly for the published table,
it shouldn't happen that it is processing both published and
unpublished changes. If the server is processing for both tables then
it is expected that the patch performs better. I think you can verify
before starting each test and after finishing each test whether the
slot is pointing at the appropriate location for the next test or
create a new slot for each with the required location.

--
With Regards,
Amit Kapila.