On Fri, May 13, 2022 at 6:02 AM Euler Taveira <eu...@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-dv48flosprmqyeyys5zwkazgd41rjr10xin...@mail.gmail.com -- With Regards, Amit Kapila.
