| Тип: | integer |
| По умолчанию: | 0 (0ms) |
| Минимальный: | 0 (0ms) |
| Максимальный: | 100 (100ms) |
| Ед. изм: | milliseconds (ms) |
| Контекст: | user |
| Перезапуск: | false |
Продолжительность времени, в миллисекундах, в течение которого будет простаивать процесс, превысивший предел стоимости. По умолчанию его значение равно нулю, то есть задержка очистки отсутствует. При положительных значениях интенсивность очистки будет зависеть от стоимости. Заметьте, что во многих системах разрешение таймера составляет 10 мс, поэтому если задать в vacuum_cost_delay значение, не кратное 10, фактически будет получен тот же результат, что и со следующим за ним кратным 10.
При настройке интенсивности очистки для vacuum_cost_delay обычно выбираются довольно небольшие значения, например 10 или 20 миллисекунд. Чтобы точнее ограничить потребление ресурсов при очистке, лучше всего изменять другие параметры стоимости очистки.
Рекомендации [EN]
Most of the time, you will want manual vacuum to execute without vacuum_delay, especially if you're using it as part of ETL. If for some reason you can't use autovacuum on an OLTP database, however, you may want to increase this to 20ms to decrease the impact vacuum has on currently running queries. Will cause vacuum to take up to twice as long to complete.
На StackOverflow
- Postgresql: database is not accepting commands to avoid wraparound data loss
- PostgreSQL11 space reuse under high delete/update rate
- Postgresql 9.3 Autovacuum not keeping up despite aggressive settings
- is there any adverse effect on DB if I set autovacuum scale factor to zero for certain tables?
- postgresql autovacuum not working although process is running