• Оптимизатор упорно выбирает медленный Seq Scan вместо Index Scan на быстрых твердотельных накопителях.
• Заниженная оценка доступной памяти кэша заставляет СУБД строить планы с неэффективными соединениями Hash Join.
• Высокое время генерации и исполнения планов запросов на современном Enterprise-оборудовании.

1. Тюнинг стоимостных весов дискового ввода-вывода

По умолчанию random_page_cost = 4.0 рассчитан на старые механические жесткие диски (HDD). Для Enterprise NVMe накопителей случайное чтение практически равно последовательному:

# /etc/postgresql/16/main/postgresql.conf

# Базовая стоимость последовательного чтения блока (эталон)
seq_page_cost = 1.0

# Стоимость случайного чтения блока (1.1 для NVMe, 1.5 для SATA SSD)
random_page_cost = 1.1

2. Расчет параметра effective_cache_size

Параметр сообщает планировщику, какой объем памяти (shared_buffers + дисковый кэш ОС Linux) доступен для кэширования таблиц и индексов. Рекомендуемое значение: 50%–75% от общего объема физической RAM сервера.

# Для сервера с 64 ГБ RAM:
effective_cache_size = 48GB

# Для сервера со 128 ГБ RAM:
effective_cache_size = 96GB

3. Сопутствующие параметры оптимизатора под NVMe

# Число одновременно выполняемых операций ввода-вывода (до 200-300 для NVMe)
effective_io_concurrency = 200

# Стоимость обработки кортежа процессором
cpu_tuple_cost = 0.01
cpu_index_tuple_cost = 0.005

4. Применение и валидация изменений

SELECT pg_reload_conf();

-- Проверка изменений в тестовом запросе
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM orders WHERE customer_id = 45120;