Skip to content

fix(trigger): add size threshold to table bloat trigger#34

Open
kqr wants to merge 1 commit into
randoneering:mainfrom
kqr:fix-impractical-table-bloat-trigger
Open

fix(trigger): add size threshold to table bloat trigger#34
kqr wants to merge 1 commit into
randoneering:mainfrom
kqr:fix-impractical-table-bloat-trigger

Conversation

@kqr

@kqr kqr commented Jul 22, 2026

Copy link
Copy Markdown

Small tables that are frequently rewritten can trivially have > 50 % table bloat even though the absolute size of the bloat is just a few kB. This is the normal, stable, desirable condition for such tables. In those cases, the suggested VACUUM FULL is an incorrect response.

The common solution to this is to add a size threshold to the table bloat trigger. There's no strict guidance for such a threshold, and different sources use different thresholds:

  • pgexperts/pgx_scripts needs 10 MB of table bloat to trigger by default
  • keithf4/pg_bloat_check lists example triggers of 10 MB and 1 GB
  • Heroku's documentation suggests a threshold of 100 MB

This commit is written with a conservative threshold to catch obvious false alarms without deviating too far from the function's earlier behaviour.

Type of Change

  • New health check
  • Bug fix
  • Performance improvement
  • Documentation update
  • Refactoring/code cleanup
  • Breaking change

Related Issues

n/a

Testing

PostgreSQL Version Compatibility

Has this code been tested against the following PostgreSQL versions?

  • PostgreSQL 15
  • PostgreSQL 16
  • PostgreSQL 17
  • PostgreSQL 18

Testing notes:

Very small change and little scope for what could go wrong. It seems to work as expected.

Managed Database Platforms

Has this code been deployed and tested on the following platforms?

  • Amazon RDS for PostgreSQL
  • Google Cloud SQL for PostgreSQL (currently unable to test)
  • Azure Database for PostgreSQL (currently unable to test)
  • Neon
  • Supabase
  • Self-managed PostgreSQL

Platform-specific notes:

Unfortunately not been able to do any testing on managed platforms.

Additional Notes

Small tables that are frequently rewritten can trivially have > 50 % table bloat
even though the absolute size of the bloat is just a few kB. This is the normal,
stable, desirable condition for such tables. In those cases, the suggested
VACUUM FULL is an incorrect response.

The common solution to this is to add a size threshold to the table bloat
trigger. There's no strict guidance for such a threshold, and different sources
use different thresholds:

- pgexperts/pgx_scripts needs 10 MB of table bloat to trigger by default
- keithf4/pg_bloat_check lists example triggers of 10 MB and 1 GB
- Heroku's documentation suggests a threshold of 100 MB

This commit is written with a conservative threshold to catch obvious false
alarms without deviating too far from the function's earlier behaviour.
@kqr
kqr requested a review from randoneering as a code owner July 22, 2026 08:01
Comment thread view_pgFirstAid.sql
q
where
bloat_pct > 50.0
and schemaname not like all(array['information_schema', 'pg_catalog', 'pg_toast', 'pg_temp%'])

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I adjusted the indentation of this filter so it's aligned with the rest of the where clause expression. Not strictly necessary, but I figured I might as well when I'm in there anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant