У меня есть очень большая таблица, 400 мм записей, которая обычно получает только вставки. Однако в последнее время мне приходится делать много обновлений записей, чтобы выполнить задачу. Это создает много мертвых кортежей. Я обновил глобальные конфиги до следующего:
autovacuum_vacuum_scale_factor = 0
autovacuum_vacuum_threshold = 10000
autovacuum_vacuum_cost_limit = 2000
autovacuum_max_workers = 6
С этими настройками я хотел, чтобы в любое время, когда мертвые кортежи превышали 10 000 записей, автоочистка очищала их.
Однако я обнаружил, что когда таблица занята другими вставками и т. д., количество мертвых кортежей не меняется. Он остается фиксированным при определенном количестве мертвых кортежей. Только когда активность базы данных ночью замедляется, автовакуум работает хорошо.
Мне нужно, чтобы автовакуум агрессивно справлялся с мертвыми кортежами в течение дня. Как бы я это сделал? Нужно ли увеличивать количество max_workers?
ОБНОВЛЕНИЕ: пользователь @Laurenz Albe предложил мне запустить некоторые показатели производительности с мертвыми кортежами и без них, чтобы продемонстрировать разницу в производительности.
Я предоставлю запрос sql и результаты EXPLAIN(ANALYZE, BUFFERS). Я изменил имя таблицы и групповой ключ для конфиденциальности.
EXPLAIN (ANALYZE, BUFFERS)
SELECT ld.upid,
MAX(ld.lid)
INTO _tt_test_with_dead_tuples
FROM big_table ld
GROUP BY ld.upid;
-- >>> С примерно 1% (3,648 млн из 383,2 млн) мертвых кортежей, результаты ниже.
HashAggregate (cost=25579746.07..25584552.97 rows=480690 width=8) (actual time=5966760.520..5975279.359 rows=16238417 loops=1)
Group Key: upid
Buffers: shared hit=3015376 read=16753169 dirtied=1759802 written=1360458
-> Seq Scan on big_table ld (cost=0.00..23642679.05 rows=387413405 width=8) (actual time=0.024..5593239.148 rows=383753513 loops=1)
Buffers: shared hit=3015376 read=16753169 dirtied=1759802 written=1360458
Planning time: 2.677 ms
Execution time: 6012319.846 ms
-- >>> При 0 мертвых кортежах результаты ниже.
HashAggregate (cost=25558409.48..25562861.52 rows=445204 width=8) (actual time=825662.640..835163.398 rows=16238417 loops=1)
Group Key: upid
Buffers: shared hit=15812 read=19753809
-> Seq Scan on big_table ld (cost=0.00..23628813.32 rows=385919232 width=8) (actual time=0.020..533386.128 rows=383753513 loops=1)
Buffers: shared hit=15812 read=19753809
Planning time: 10.109 ms
Execution time: 843319.731 ms
