Какие настройки базы данных можно изменить для улучшения производительности, например work_mem

Что проверяют

Понимаете ли вы, как PostgreSQL расходует память и почему крутить параметры вслепую опасно. Для C#-разработчика это ещё и вопрос о связи настроек сервера с тем, как приложение держит соединения через Npgsql. Следом обычно спрашивают, как понять, что work_mem не хватает.

Как отвечать

Назовите основные параметры и сразу их подвох:

• work_mem (по умолчанию 4 МБ): память на одну операцию сортировки или хеширования, а не на запрос. План с тремя сортировками и хеш-соединением в параллельных воркерах возьмёт её многократно. Нехватку видно в EXPLAIN (ANALYZE, BUFFERS) по Sort Method: external merge с записью на диск и по log_temp_files. Поднимать лучше точечно: SET work_mem для отчётного запроса или ALTER ROLE ... SET для роли аналитики;
• shared_buffers (по умолчанию 128 МБ): собственный кеш страниц. Типичная отправная точка около четверти RAM, остальное работает как кеш ОС;
• effective_cache_size: ничего не выделяет, это подсказка планировщику, сколько данных, скорее всего, уже в памяти;
• maintenance_work_mem: для VACUUM, CREATE INDEX, добавления внешних ключей;
• random_page_cost: по умолчанию 4, это расчёт на HDD. На SSD обычно ставят около 1.1, иначе планировщик недооценивает индексы;
• max_wal_size и checkpoint_timeout: слишком частые чекпоинты дают пилу на записи;
• автовакуум: на больших таблицах с частыми обновлениями пороги по умолчанию срабатывают поздно, их подкручивают для конкретной таблицы.

Отдельно про max_connections. Каждое соединение в PostgreSQL это отдельный процесс, поэтому поднимать лимит до тысяч вредно. Лучше пул в приложении (у Npgsql он включён по умолчанию, размер задаёт Max Pool Size) и PgBouncer, когда экземпляров сервиса много.

Где спотыкаются

Ставят work_mem в гигабайт глобально. При сотне соединений и параллельных запросах сервер ловит OOM.

Начинают с настроек, а не с запроса. Чаще проблема в пропущенном индексе или в N+1 из EF Core, и pg_stat_statements покажет это быстрее любого тюнинга.

Путают effective_cache_size с выделением памяти и «экономят» на нём.