Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w52Ot-002pfy-0K for pgsql-general@arkaria.postgresql.org; Tue, 24 Mar 2026 14:06:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w52Or-006yhT-1l for pgsql-general@arkaria.postgresql.org; Tue, 24 Mar 2026 14:06:29 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w52Or-006yhG-0f for pgsql-general@lists.postgresql.org; Tue, 24 Mar 2026 14:06:29 +0000 Received: from zcsmtaf01-pub.meteo.fr ([137.129.63.5]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w52Oo-00000000ncq-1fc4 for pgsql-general@lists.postgresql.org; Tue, 24 Mar 2026 14:06:28 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by zcsmtaf01-pub.meteo.fr (Postfix) with ESMTP id 0F3F944D4B91 for ; Tue, 24 Mar 2026 14:06:24 +0000 (GMT) Received: from zcsmtaf01-pub.meteo.fr ([127.0.0.1]) by localhost (zcsmtaf01.meteo.fr [127.0.0.1]) (amavis, port 10032) with ESMTP id Re2TlGWEUBNB for ; Tue, 24 Mar 2026 14:06:23 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zcsmtaf01-pub.meteo.fr (Postfix) with ESMTP id E6C1D44D4B8E for ; Tue, 24 Mar 2026 14:06:23 +0000 (GMT) X-Virus-Scanned: amavis at meteo.fr Received: from zcsmtaf01-pub.meteo.fr ([127.0.0.1]) by localhost (zcsmtaf01.meteo.fr [127.0.0.1]) (amavis, port 10026) with ESMTP id rlg4FNZ2p6mg for ; Tue, 24 Mar 2026 14:06:23 +0000 (GMT) Received: from zcsmsm04.meteo.fr (zcsmsm04.meteo.fr [172.24.3.124]) by zcsmtaf01-pub.meteo.fr (Postfix) with ESMTP id AF0F844D4B91 for ; Tue, 24 Mar 2026 14:06:23 +0000 (GMT) Date: Tue, 24 Mar 2026 14:06:23 +0000 (GMT) From: PALAYRET Jacques To: pgsql-general@lists.postgresql.org Message-ID: <531047943.370846639.1774361183685.JavaMail.zimbra@meteo.fr> Subject: Logical replication in PostgreSQL Amount of subscriber vs publisher WALs MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_68fd56d3-467e-4e7c-b806-e356833cbe7c" X-Originating-IP: [172.24.2.157] X-Mailer: Zimbra 9.0.0_GA_4583 (ZimbraWebClient - FF128 (Win)/9.0.0_GA_4583) Thread-Index: t5LlkICwqsRtXc/OMOLXOapVC6QOVA== Thread-Topic: Logical replication in PostgreSQL Amount of subscriber vs publisher WALs List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --=_68fd56d3-467e-4e7c-b806-e356833cbe7c Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello,=20 The amount of WAL generated by an SQL INSERT or UPDATE statement applied to= a table with multiple indexes can be much greater than the size of the tab= le (table + index).=20 For example, an INSERT statement in an empty table (with 3 indexes) can gen= erate WALs twice the size of the table (table + index).=20 This difference (even for an INSERT) may seem surprising, but it's understa= ndable.=20 What's less intuitive is that, according to my tests, with logical replicat= ion in PostgreSQL, the amount of WAL generated by an SQL statement can be v= ery different between the subscriber server (the replica) and the publisher= server (the provider).=20 Is this accurate? Sometimes 1.5 or 2 times greater?=20 Regards=20 ----- M=C3=A9t=C3=A9o-France -----=20 PALAYRET Jacques=20 DCSC/GDC=20 jacques.palayret@meteo.fr=20 Fixe : +33 561078319=20 --=_68fd56d3-467e-4e7c-b806-e356833cbe7c Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello,

The amount of WAL generated by an SQL INSERT or UPDATE statem= ent applied to a table with multiple indexes can be much greater than the s= ize of the table (table + index).
For example, an INSERT statement in an= empty table (with 3 indexes) can generate WALs twice the size of the table= (table + index).
This difference (even for an INSERT) may seem surprisi= ng, but it's understandable.

What's less intuitive is that, a= ccording to my tests, with logical replication in PostgreSQL, the amount of= WAL generated by an SQL statement can be very different between the subscr= iber server (the replica) and the publisher server (the provider).
Is th= is accurate? Sometimes 1.5 or 2 times greater?

Reg= ards
----- M= =C3=A9t=C3=A9o-France -----
PALAYRET Jacques
DCSC/GDC
jacques.pala= yret@meteo.fr
Fixe : +33 561078319
--=_68fd56d3-467e-4e7c-b806-e356833cbe7c--