PgConf.Russia 2020

В рамках доклада поговорим о хранимых процедурах и функциях и коде внутри базы данных в целом. Посмотрим на хранимки с разных сторон: глазами DBA, разработчика баз данных и разработчика серверной части. Попытаемся понять что такого особенного в хранимых процедурах, что зачастую препятствует применению сложившихся практик по работе с исходным кодом. Поговорим о том как выглядят best practice по работе с кодом в разрезе хранимых процедур.

Доклад в большей степени ориентирован на разработчиков баз данных и серверных разработчиков, и является скорее мотивационным, чем хардкорно-техническим.

В докладе мы хотим рассказать об опыте миграции одной большой системы с Oracle на PostgreSQL. Сама система построена на стеке PHP + Oracle, её отличительной особенностью было то, что вся бизнес-логика была реализована в PL/SQL коде. В СУБД - это более 3000 пакетов с 4-10 функциями (процедурами) в каждом. В PHP - более 10000 форм со вставками анонимных блоков, используемых для получения данных, обработки и сохранения результатов в Oracle.

Для решения этой крайне объемной работы мы взяли ANTLR4 (синтаксический анализатор для чтения, обработки, выполнения или перевода структурированного текста), грамматику PL/SQL и создали автоматический конвертер, который позволяет преобразовать все объекты схемы и нашей системы из Oracle в рабочий код для PostgreSQL.

pg_repack является популярным инструментом для устранения bloat-a таблиц и индексов в постгресе. В большинстве случаев он отлично справляется с проблемой. Но как оказалось, в случае использования такой фичи постгреса как deferred ограничения, использование pg_repack либо сильно усложняется, либо становится невозможным. Я расскажу о том, как мы обнаружили эту проблему и опишу возможные способы ее решения - от встроенных средств постгреса до небольшого патча pg_repack.

Одну из самых массовых ветвей распространения PostgreSQL в России занимает 1С. В докладе хотел бы поделиться мыслями о том, чего не хватает в PostgreSQL по мнению тех, кто работает с 1С.