Как сломать PostgreSQL Логично, что большинство гайдов по Postgres посвящены тому, как сделать его быстрее, выше, сильнее. А вы когда-нибудь задумывались, как наоборот сделать его медленнее? Зачем? Ну, во-первых, это прекрасный способ разобраться, как СУБД работает и что обеспечивает ее производительность, а во-вторых, почему бы и нет. Если вы об этом не задумывались, не страшно. Нашелся экспериментатор, который сделал это за вас и замедлил Postgres в 42 000 раз. По условиям задачи, было тормозить его можно было только изменениями параметров `postgresql.conf`. Иначе неспортивно. Итак, что же он сделал? 🔵Ужал кэш. Прочитав блок данных, Postgres записывает его в кэш, и это позволяет обрабатывать следующие запросы быстрее, чем если бы СУБД каждый раз обращалась к диску. Ряд экспериментов показал, что 2 МБ — это минимальное возможное значение, при котором Postgres может работать, просто очень медленно, обрабатывая 500 меньше транзакций в секунду. На старте, с кэшем в 10 ГБ у него было 7082 TPS. 🔵Завалил СУБД фоновыми задачами. В частности — заставил ежесекундно запускать autovacuum, процесс, с помощью которого Postgres находит и заполняет пустое место на диске новыми. Из-за ужатого кэша СУБД была вынуждена часто обращаться к диску, и скорость упала до 293 TPS. 🔵Заставил записывать все изменения в WAL перед внесением в базу. TPS упал ниже 100. 🔵Фактически отключил возможность пользоваться индексами, увеличив параметры `random_page_cost `и `cpu_index_tuple_cost `и заставив сканировать все страницы последовательно. Кэш пришлось увеличить до 8МБ, но TPS все равно стал ниже единицы. 🔵И наконец-то перевел Postgres в однопоточный режим, выставив параметры` io_method = worker` и затем `io_workers = 1`. Это уронило TPS ниже 0,1. Дело сделано, база еле ползает. В конце статьи перечислены все параметры, в которые вносились изменения, если вдруг кто-то захочет повторить. А что вы изменили бы, если бы хотели замедлить СУБД?