Re: table bloat very fast and free space can not be reused - Mailing list pgsql-performance

From Kristjan Mustkivi
Subject Re: table bloat very fast and free space can not be reused
Date
Msg-id CAOQPKatQ0NCP5vDCZ_pz_JQkyM+AP=nPL5wPY3awWVoZXA4T1A@mail.gmail.com
Whole thread
In response to table bloat very fast and free space can not be reused  (James Pang <jamespang886@gmail.com>)
Responses Re: table bloat very fast and free space can not be reused
List pgsql-performance
On Sun, Apr 19, 2026 at 4:28 AM James Pang <jamespang886@gmail.com> wrote:
>
> 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
sizedid not increased quickly. but in target pg v17 , by pglogical apply, we found table increased very quickly , table
sizegot doubled in days. 
>     Vacuum analyze did not help , only vacuum full can help. pgstattuple show most of space are free space , that
muchmore than source.  it looks like these replicate DML always asking new pages instead of reuse existing freespace. 

Hi,

We have had the exact same problem in the past - a large json column
getting very frequent updates (hundreds even thousand per minute) on
the source and the replica side table bloating up. No amount of tuning
attempts made any difference (conversion of json to text, different
table specific autovacuum settings etc). Eventually, the table was
taken out of the replication and later on made UNLOGGED which also
freed up a giant swathes of storage from WAL written. Such design was
then called an antipattern and has not been allowed since.

With best regards,

Kristjan



pgsql-performance by date:

Previous
From: James Pang
Date:
Subject: Re: table bloat very fast and free space can not be reused
Next
From: David Rowley
Date:
Subject: Re: Significant performance issues with array_agg() + HashAggregate plans on Postgres 17