История одной миграции

В данном рассказе мы хотим рассказать о том, как команда Microsoft, созданная из двух различных команд, работала над проектом, решала проблемы миграции, используя ora2pg, и смогла доказать, что Postgres Single Server может демонстрировать хорошую производительность наравне с Oracle Exadata. Мы расскажем о наших методах работы, а также о ряде основных проблем технического характера, с которыми мы столкнулись, включая миграцию выражений BULK COLLECT, иерархических запросов, курсорных выражений REF CURSOR и других, более сложных конструкций Oracle.

Наша история о практическом подтверждении гипотезы, которое доказало, что Postgres может демонстрировать такую же производительность, как Oracle Exadata. Схема мигрируемой БД была не самой простой. Скорее, наоборот. Код был нагружен динамическими запросами, выражениями BULK COLLECT, вложенными циклами, операторами CONNECT BY, глобальными переменными и множеством зависимостей. Инструмент Ora2pg очень помог нам с преобразованием схемы БД, но всё равно осталось много работы, которую можно было сделать только вручную. Оценки, которые мы получили благодаря инструменту, также оказались очень далеки от истины, поскольку требовалась не просто миграция кода, а изменение его архитектуры. В рамках нашего доклада мы рассмотрим следующие подтемы:

• Как (не) работают оценки
• Как мы справились с миграцией выражений BULK COLLECT
• Почему мы избавились от выражений REF CURSOR
• Как мы застряли на фазе тестирования одного из пакетов и как помощь друга помогла нам в решении этой проблемы.
• Как мы справились с иерархическими запросами и детализацией иерархии

Сколько нужно инженеров, чтобы скобки заработали?

Недавно появившийся в PostgreSQL, jsonb subscripting не выглядит так же захватывающе, как другие улучшения в jsonb. Но те изменения, которые видны пользователю - всего лишь верхушка айсберга. Как много людей было вовлечено в разработку, и какие решения были сделаны в дизайне? Как много времени это заняло, и какие хорошие/плохие идеи существуют для продвижения патча? Эти и несколько других вопросов будут целью это презентации.

psycopg3: как Питон полюбил Постгрес

На сегодняшний день Python является одним из наиболее часто используемых языков программирования в мире. Он прост в изучении и использовании и легко совместим с любыми известными сервисами и протоколами. psycopg2 - наиболее часто используемый драйвер PostgreSQL для Python: он обеспечивает хорошую производительность и делает взаимодействие между ЯП и СУБД максимально удобным.

За последние годы Python существенно изменился, и его первоклассная поддержка асинхронного программирования меняет способ написания новых программ. В PostgreSQL также было внесено множество изменений, поэтому требуется новое поколение драйвера, который позволит питонистам использовать все возможности Postgres по максимуму.

psycopg3 - это новое поколение наиболее часто используемой библиотеки-адаптера Python-PostgreSQL: она предлагает знакомый интерфейс и удобный процесс обновления, кроме того, она спроектирована для получения максимальной производительности от базы данных и ЯП: она поддерживает асинхронное программирование, связываемые переменные (prepared statements), двоичные параметры.

psycopg3 также экспериментирует с инновационной поддержкой JSONB и конвейерной обработкой запросов! Приходите и узнайте, что нового происходит на стыке вашего любимого языка программирования и базы данных!

PostgreSQL и стандарты SQL

PostgreSQL - одна из СУБД, в наибольшей степени соответствующая стандартам. В этом докладе будет рассмотрено влияние Постгреса на стандарт SQL и фичи из стандарта, которые были релизованы в Постгресе, в том числе фичи, планирующиеся в 14й и последующих версиях.