Что нам ждать от PostgreSQL 13?

"Заморозка разработки" (feature freeze) PostgreSQL 13 запланирована на апрель 2020. Впереди ещё два commitfest'а, которые принимают новые патчи. Что мы можем сказать про PostgreSQL 13? Возможно сработает закон чередования и в нём окажется не так много прорывных фич, как в PostgreSQL 12. Даже если и так, то это будет хороший эволюционный релиз, куда войдёт много небольших фич, а также инфраструктурных изменений, готовящих постгрес к новому рывку. В докладе я расскажу о всех ожидаемых новинках PostgreSQL 13. О них можно будет судить достаточно точно, потому что останется уже только один последний commitfest, результаты которого можно будет прогнозировать.

Как я перестал беспокоиться и перенес 60K строк из 150 процедур PL/SQL в Postgres.

В докладе рассказывается об опыте переноса серверного приложения, работающего на полигоне железных дорог от Калининграда до Хабаровска, с Oracle 11g Standard Edition на ванильный PostgreSQL 11.5.
На момент начала миграции база данных насчитывала порядка 200 хранимых процедур на языке Oracle PL/SQL общим объемом порядка 60000 строк (которые создавались с 2006 года, т.е. уже более 12 лет), около 250 таблиц и 50 Гбайт данных.
Доклад содержит описание сопровождавших этот процесс приключений, приятных и неприятных открытий, а также пролог, эпилог и хэппи-энд.

Повествование ведется от лица пользователя Oracle, открывающего для себя Postgres.

GraphQl-бэкенд на PostgreSQL и plv8

Недавно мне пришлось поработать над проектом, где для запросов к бэкенду на .NET Core использовали GraphQl, о чём потом пожалели. Дело в том, что GraphQl-запрос представляет собой объект с динамическим набором полей и иерархией любой вложенности. Обрабатывать такие объекты на языке со статической и сильной типизацией, да ещё и через ORM, как это предлагают библиотечные решения – очень неудобно. И тогда мне пришла идея использовать plv8 и разбирать запросы в формате GraphQl прямо на стороне БД. За пару часов я написал работающий прототип, реализующий функционал, который разрабатывали более месяца! Затем было сделано несколько усовершенствований, всё это я собираюсь показать. Тем, кто собирается в своих проектах использовать GraphQl, а не REST, информация из данного доклада может особенно пригодиться и возможно поможет сэкономить уйму времени.

The possibilities of profiling plpgsql code - available tools

I like stored procedures - it is great technology. But like any other technologies it allows to write not well optimized code. It is not easy to write optimized code, sql statements in complex large applications. On second hand, there are some tools, that can be used very easily, that can help. Postgres has built-in tracking functions possibility. There are PLProfiler and plpgsql_check. With these tools is easy work to detect slow part of applications.With this knowledge, the fix of performance issue is less magic.