Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding - Mailing list pgsql-hackers

From Ajin Cherian
Subject Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding
Date
Msg-id CAFPTHDbQb1tBNwL_UuQT4a4RphT2VjRjzjDmU1tAoEX6aSNZmg@mail.gmail.com
Whole thread Raw
In response to Proposal: Filter irrelevant change before reassemble transactions during logical decoding  (li jie <ggysxcq@gmail.com>)
Responses Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding
List pgsql-hackers
On Tue, Jun 3, 2025 at 4:25 PM Ajin Cherian <itsajin@gmail.com> wrote:
>
> On Tue, Jun 3, 2025 at 3:55 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> >
> > You haven't shared the exact test scenario, but I am assuming the
> > above tests are for very large transactions, as you are comparing
> > streaming and non-streaming modes. Can we see results with short
> > transaction size (say one insert or one update, or one delete) as
> > well?
> >
>
> Attaching the scripts I used for my tests. Yes, I used transactions
> with large inserts. I will redo the tests with short single inserts
> and share the results here.

I redid the tests with 10k small transactions (single inserts) and the
results are not great with the patch:

No transactions published: Patched code performs 12.33% faster than head code.

Half transactions published: Patched code is 4.97% slower than head.

All transactions published: Patched code is 6.70% slower than head.

Attaching the script and the bar graph.

regards,
Ajin Cherian
Fujitsu Australia

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Enable data checksums by default
Next
From: shveta malik
Date:
Subject: Re: Conflict detection for update_deleted in logical replication