PostgreSQL why table bloat ratio is higher than autovacuum_vacuum_scale_factor

user_3143770 0
Viewed 36

I found that bloat ratio of feedback_entity is 48%

current_database | schemaname |       tblname         |  real_size  | extra_size |   extra_ratio    | fillfactor | bloat_size |   bloat_ratio    | is_na 
 stackdb         | public     | feedback_entity       |  5743878144 | 2785599488 | 48.4968416488746 |        100 | 2785599488 | 48.4968416488746 | f

but when I check autovacuum setting it has autovaccum setting of 10%

stackdb=> show autovacuum_vacuum_scale_factor;
 autovacuum_vacuum_scale_factor 
--------------------------------
 0.1
(1 row)

stackdb=> show autovacuum_vacuum_threshold;
 autovacuum_vacuum_threshold 
-----------------------------
 50
(1 row)

Also: Autovacuum setting is on. Autovacuum for mentioned table are running regularly at defined threshold

My Question is when auto vacuum is running at 10% of dead tuples why would bloat size increase to 48%. I have seen similar behaviour in hundreds of databases/tables. Why table bloat is always increasing and doesn't come down after every vacuum.

postgresql performance
1 Answers

The query that you used to calculate the table bloat is unreliable. To determine the actual bloat, use the pgstattuple extension and query like this:

SELECT * FROM pgstattuple('public.feedback_entity');

But the table may really be bloated. There are two major reasons for that:

  1. autovacuum runs and finishes in a reasonable time, but it cannot clean up the dead tuples. That may be because there is a long-running open transaction, an abandoned replication slot or a prepared transaction. See this article for details.

  2. autovacuum runs too slow, so that dead rows are generated faster than it can clean them up. The symptoms are lots of dead tuples in pg_stat_user_tables and autovacuum processes that keep running forever. The straightforward solution is to use ALTER TABLE to increase autovacuum_vacuum_cost_limit or reduce autovacuum_vacuum_cost_delay for the afflicted table. An alternative approach, if possible, is to use HOT updates.

user_64643080
Related