Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.8\))
Subject: Re: table bloat very fast and free space can not be reused
From: Christophe Pettus <xof@thebuild.com>
In-Reply-To: 
 <CAHgTRff=eH1GwVb=ENMzX6hBEajdTccCQbeVRkj4OtYLm69a9g@mail.gmail.com>
Date: Sat, 18 Apr 2026 20:56:52 -0700
Cc: pgsql-performance@lists.postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6EEE234B-D3DC-48D9-97EE-0A86D63554BC@thebuild.com>
References: 
 <CAHgTRff=eH1GwVb=ENMzX6hBEajdTccCQbeVRkj4OtYLm69a9g@mail.gmail.com>
To: James Pang <jamespang886@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/6EEE234B-D3DC-48D9-97EE-0A86D63554BC%40thebuild.com>
Precedence: bulk


> On Apr 18, 2026, at 18:28, James Pang <jamespang886@gmail.com> wrote:
>=20
> experts:
>      source database v14 ,  pglogical extension 2.4.5 replication to =
new 17, source table very frequent UPDATEs /DELETES /INSERTS and has two =
text and jsonb. in source database, application update/delete/insert =
through SQL, table size did not increased quickly. but in target pg v17 =
, by pglogical apply, we found table increased very quickly , table size =
got doubled in days. =20
>     Vacuum analyze did not help , only vacuum full can help. =
pgstattuple show most of space are free space , that much more than =
source.  it looks like these replicate DML always asking new pages =
instead of reuse existing freespace.=20
>     Thanks,
>=20
> James

Hello,

1. First, are you *sure* that the free space is the source of the bloat, =
and not dead tuples?  Could you share the queries you ran to detrmine =
this?

2. Have you set fillfactor to anything besides 100 on either the source =
or the destination?

3. You might consider using in-core logical replication rather than =
pglogical for this.  By PostgreSQL v14, in-core logical replication is =
likely a better choice.

Best,
-- Christophe=