PostgreSQL и временные таблицы. Часть 2: почему 1024 счётчиков бывает мало
<img src="https://habrastorage.org/getpro/habr/upload_files/8cd/417/64d/8cd41764d1a9a0234a85641a60ab504c.jpg" /><p>В 2023 году мы <a href="https://habr.com/ru/companies/lsfusion/articles/754476/" rel="noopener nofollow">писали</a> о временных таблицах в PostgreSQL и о том, как перенести их на RAM-диск. Это помогло: в наших измерениях доля <code>ext4</code> в профиле процессора упала с 13,5% до 1,6%, и про диск мы с тех пор не вспоминали. Однако создание, очистка и удаление временных таблиц остались обычным DDL — с изменениями системного каталога и сильными блокировками, которые держатся до конца транзакции. Оказалось, что это отдельная цена, и платить её приходится в самых неожиданных местах.</p><p>На одном сервере активные бэкенды периодически застревали в ожиданиях <code>LWLock:LockManager</code>. На другом отставала логическая репликация и накапливался WAL. Выглядело это совершенно по-разному, а разбираться в обоих случаях пришлось в одном и том же: в том, что происходит в PostgreSQL, когда временные таблицы создаются и очищаются тысячами. Начнём с блокировок — там обнаружился массив из 1024 счётчиков, который занимает четыре килобайта, не настраивается и не менялся с 2011 года, и выяснилось, что временные таблицы одной сессии могут лишать обычные запросы всех остальных сессий быстрого пути получения блокировок.</p> <a href="https://habr.com/ru/articles/1080150/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1080150#habracut">Читать далее</a>