Записки программиста

При разработке пача для PostgreSQL иногда требуется добавить новую функцию, чтобы ею можно было вызывать из SQL. Недавно вопрос о том, как это делается, задали мне два разных человека в течение одной недели. И хотя это простая задача, информация, по всей видимости, является востребованной. Давайте же рассмотрим решение.

PGVector — это открытое (лицензия MIT) расширение PostgreSQL, решающее задачу поиска схожих векторов. Что еще за вектора такие, и зачем кому-то искать среди них похожие? Попробуем разобраться на конкретном примере.

Системный каталог, или просто каталог — это таблицы, в которых PostgreSQL хранит информацию обо всех остальных объектах, хранящихся в базе данных. К ним относятся таблицы, функции, триггеры, и т.д. Обращение к системному каталогу происходит часто, поэтому для него предусмотрен кэш. Давайте же разберемся, как этот кэш устроен.

Расширениям PostgreSQL могут требоваться какие-то параметры конфигурации. Для решения данной задачи в PostgreSQL имеется фреймворк под названием Grand Unified Configuration. GUC используется как расширениями, так и самой системой. Давайте же разберемся, как воспользоваться GUC из расширения.

При разработке расширений PostgreSQL иногда требуется запустить отдельный процесс, который выполняет какие-то действия в фоне, без участия пользователя. Такой процесс называется background worker. Давайте разберемся, как все это устроено.

Карта свободного пространства, она же free space map или FSM — это структура в PostgreSQL, предназначенная для быстрого поиска страницы c заданным количеством свободного места. Без FSM при записи новых данных СУБД приходилось бы сканировать всю кучу, либо записывать данные в ее конец.

Ранее в постах серии «Внутренности PostgreSQL» несколько раз упоминалось нечто под названием visibility map, или карта видимости (случай один, случай два и далее по ссылкам). Однако не сообщалось, что это за штука такая и почему она важна. Пришло время заполнить данный пробел.

Благодаря посту Внутренности PostgreSQL: ProcArray и CLOG мы узнали, как PostgreSQL определяет состояние транзакции по ее идентификатору, или XID. Однако из статьи Внутренности PostgreSQL: страницы и кортежи мы также помним, что XID является 32-х битным числом. Несложными математическими расчетами несложно понять, что даже при скромных нагрузках (~1000 TPS), уникальные XID’ы могут закончится за несколько месяцев. Давайте разберемся, как PostgreSQL решает эту проблему.

PostgreSQL хранит данные в страницах, а страницы кэшируются в разделяемых буферах. Казалось бы, в случае аварийной остановки грязные страницы не будут записаны на диск, и часть данных пропадет. Чтобы такого не происходило, СУБД пишет журнал предзаписи, он же Write Ahead Log, или WAL.

Когда-то давно мы научились собирать PostgreSQL из исходников. Тогда в проекте использовалась система сборки Autotools. Однако в PostgreSQL 16, который на момент написания этих строк еще находится в разработке, была добавлена поддержка альтернативной системы сборки, Meson. Давайте разберемся, как ею пользоваться.