On Fri, May 13, 2022 at 6:02 AM Euler Taveira <euler@eulerto.com> wrote:
>
> On Thu, May 12, 2022, at 11:22 AM, Bruce Momjian wrote:
>
> On Thu, May 12, 2022 at 11:12:54AM -0300, Euler Taveira wrote:
> OB> On Thu, May 12, 2022, at 11:03 AM, Bruce Momjian wrote:
> >
> > I looked at that but thought that everyone would already assume we
> > skipped replication of empty transactions, and I didn't see much impact
> > for the user, so I didn't include it.
> >
> > It certainly has an impact on heavy workloads that replicate tables with few
> > modifications. It receives a high traffic of 'begin' and 'commit' messages that
> > the previous Postgres versions have to handle (discard). I would classify it as
> > a performance improvement for logical replication. Don't have a strong opinion
> > if it should be mentioned or not.
>
> Oh, so your point is that a transaction that only has SELECT would
> previously send an empty transaction? I thought this was only for apps
> that create literal empty transactions, which seem rare.
>
> No. It should be a write transaction. If you have a replication setup that
> publish only table foo (that isn't modified often) and most of your
> workload does not contain table foo, Postgres sends 'begin' and 'commit'
> messages to subscriber even if there is no change to replicate.
>
It reduces network traffic and improves performance by 3-14% on simple
tests [1] like the one shown by Euler. I see a value in adding this as
for the workloads where it hits, it seems more than 99% of network
traffic [2] is due to these empty messages.
[1] -
https://www.postgresql.org/message-id/OSZPR01MB63105A71CFAA46F5BD7C9D7CFD1E9%40OSZPR01MB6310.jpnprd01.prod.outlook.com
[2] - https://www.postgresql.org/message-id/CAMkU=1yohp9-dv48FLoSPrMqYEyyS5ZWkaZGD41RJr10xiNo_Q@mail.gmail.com
--
With Regards,
Amit Kapila.
