> More important question is, how can I find out why the index was not auto vacuumed.
You should have a look at pg_stat_user_tables. It'll let you know if
the table is being autovacuumed and how often. If you're concerned
about autovacuum not running properly, then you might want to lower
log_autovacuum_min_duration. Generally, anything that takes a
conflicting lock will cause autovacuum to cancel so that the
conflicting locker can get through. Things like ALTER TABLE or even
an ANALYZE running will cancel most autovacuum runs on tables.
Also, this is a fairly large table and you do have the standard
autovacuum settings. Going by pgstattuple, the table has 39652836
tuples. Autovacuum will trigger when the statistics indicate that 20%
of tuples are dead, which is about 8 million tuples. Perhaps that's
enough for the index scan to have to skip over a large enough number
of dead tuples to make it slow. You might want to consider lowering
the autovacuum scale factor for this table.
Also, ensure you're not doing anything like calling pg_stat_reset();
It might be worth showing us the output of:
select * from pg_stat_user_tables where relid = 'media.block'::regclass;
Thank you for your suggestion, this is really very helpful.
select * from pg_stat_user_tables where relid = 'media.block'::regclass;
-------------------+-----------------------------+
relid |25872 |
schemaname |media |
relname |block |
seq_scan |8 |
seq_tup_read |139018370 |
idx_scan |45023556 |
idx_tup_fetch |37461539 |
n_tup_ins |7556051 |
n_tup_upd |7577720 |
n_tup_del |0 |
n_tup_hot_upd |0 |
n_live_tup |39782042 |
n_dead_tup |5938057 |
n_mod_since_analyze|1653427 |
n_ins_since_vacuum |5736676 |
last_vacuum | |
last_autovacuum |2023-08-17 22:39:29.383 +0200|
last_analyze | |
last_autoanalyze |2023-08-22 16:02:56.093 +0200|
vacuum_count |0 |
autovacuum_count |1 |
analyze_count |0 |
autoanalyze_count |4 |
Regards,
Laszlo
