Re: Table bloat threshold limit to trigger repack

On 2026-02-08 15:14:37 +0530, Durgamahesh Manne wrote:
> On Sun, 8 Feb, 2026, 13:15 Ron Johnson, <ronljohnsonjr(at)gmail(dot)com> wrote:
> On Sun, Feb 8, 2026 at 12:43 AM Durgamahesh Manne <
> maheshpostgres9(at)gmail(dot)com> wrote:
> On Sun, 8 Feb, 2026, 10:59 Ron Johnson, <ronljohnsonjr(at)gmail(dot)com>
> wrote:
> On Sat, Feb 7, 2026 at 11:19 PM Durgamahesh Manne <
> maheshpostgres9(at)gmail(dot)com> wrote:
> How much table bloat is acceptable before it affects
> performance in PostgreSQL? 
>
> How big is the table? (For small tables, it doesn't matter.) How
> active is it?  How frequently are records updated?
>
> Table size 100gb
> I use pgstattuple_approx to get Table bloat is about 16gb as of now
> since after repack is done on 27th of January 
> Fillfactor already in place
> It's very critical application with updates on non partitioned table 
>
>
> What did you set the fillfactor to?
> Have you minimized the number of indexes?  (That lets HOT work better.)
> How long does it take to VACUUM the table?
>
> Fillfactor 80

With a fillfactor of 80 you should expect at least 20% of unused space,
or a "bloat" of (100 / 80) - 100 = 25 %.

Your 16 GB seem to be less than that which is a bit unexpected, but
might happen if you have an update-heavy workload. If you have 16 GB
more bloat than expected (i.e. you have 67 GB of data and therefore
expected a table size of 67 * 100 / 80 = 84 GB, but have 100 GB
instead), that may be worth investigating but isn't terribly concerning
if you have many inserts.

hjp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp(at)hjp(dot)at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"