Re: logical replication empty transactions - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: logical replication empty transactions
Date
Msg-id CAFiTN-u6KAHTOLz-RdDuTjY9NuLHdKrLCiTe4-WjXTs_3ihAxw@mail.gmail.com
Whole thread Raw
In response to Re: logical replication empty transactions  (Euler Taveira <euler@timbira.com.br>)
Responses Re: logical replication empty transactions  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Sat, Nov 9, 2019 at 7:29 AM Euler Taveira <euler@timbira.com.br> wrote:
>
> Em seg., 21 de out. de 2019 às 21:20, Jeff Janes
> <jeff.janes@gmail.com> escreveu:
> >
> > After setting up logical replication of a slowly changing table using the built in pub/sub facility, I noticed way
morenetwork traffic than made sense.  Looking into I see that every transaction in that database on the master gets
sentto the replica.  99.999+% of them are empty transactions ('B' message and 'C' message with nothing in between)
becausethe transactions don't touch any tables in the publication, only non-replicated tables.  Is doing it this way
necessaryfor some reason?  Couldn't we hold the transmission of 'B' until something else comes along, and then if that
nextthing is 'C' drop both of them? 
> >
> That is not optimal. Those empty transactions is a waste of bandwidth.
> We can suppress them if no changes will be sent. test_decoding
> implements "skip empty transaction" as you described above and I did
> something similar to it. Patch is attached.

I think this significantly reduces the network bandwidth for empty
transactions.  I have briefly reviewed the patch and it looks good to
me.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: ALTER tbl rewrite loses CLUSTER ON index
Next
From: Amit Langote
Date:
Subject: Re: [PATCH] Add schema and table names to partition error