В статье дан качественный тест, проявляющий проблему конкуренции за блокировки типа LockManager. В статьях @drema201 (АО "Гнивц") описываются интересные проблемы, возникающе при реальной эксплуатации и было упомянуто, что проблема решена в 18 версии PostgreSQL без описания того, как решена. Эта статья закрывает пробел. Начиная с 18 версии, проблема конкуренции LWLock:LockManager при выполнении запросов к большому числу таблиц, индексов, секций ("отношений") устранена. Также даётся ответ на вопрос: если fastpath блокировки хранятся отдельно для каждого процесса, как другие процессы проверяют наличие блокировок? В статье описано, почему блокировки по быстрому пути (fastpath) так эффективны и почему новшества в PostgreSQL, появившиеся в 18 так важны на практике.При выполнении запроса SELECT к таблице PostgreSQL блокирует не только саму таблицу, но и ВСЕ её индексы с помощью Access Share ещё на этапе планирования. Все эти блокировки помещаются в разделяемую память и защищаются блокировками LWLock. На компьютерах с большим числом ядер, обслуживающих множество простых запросов (например, поиск по первичному ключу), серверные процессы постоянно конкурируют за один и тот же раздел структуры блокировок LWLock, которая находится в разделяемой памяти. Классическое узкое место. Читать далее