On Tue, Feb 25, 2025 at 3:26 PM Ajin Cherian <itsajin@gmail.com> wrote:
>
> On Fri, Feb 21, 2025 at 2:24 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Fri, Feb 21, 2025 at 7:57 AM Ajin Cherian <itsajin@gmail.com> wrote:
> > > 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.
>
> Yes, you are right, I modified the tests to drop the slot and create a
> new slot advance to current_lsn and now I see a fractionally better
> performance in head code when all transactions are published.
> Graph attached.
>
Just to summarize and clarify:
The patched code significantly improves performance when no
transactions are published, reducing execution time from ~54,100 ms
(head code) to ~17,700 ms—a nearly 70% improvement.
When half of the transactions are published, the patched code also
shows a notable performance gain, reducing execution time from ~62,800
ms to ~44,500 ms (~29% faster).
When all transactions are published, the patched code is only 0.53%
slower than the head code, indicating a negligible performance
degradation.
regards,
Ajin Cherian
Fujitsu Australia
