Как сохранить статистику при мажорном обновлении, и что за это бывает

Ни для кого не секрет, что статистика не переносится при мажорном обновлении. Для небольших и не сильно нагруженных баз это не проблема, можно быстро собрать новую статистику. Но у нас есть базы объемом порядка 5ТБ и нагрузкой порядка 100k rps, для которых это стало большой проблемой: взлетая без статистики, реплики даже не могли накатывать WAL. В своем докладе расскажу, на какие хитрости мы пошли, чтобы произвести обновление этих баз в условиях требований 100% доступности read only, о том, какие ошибки допустили, и о том как эти ошибки мучительно исправляли. Результатом этих ошибок стало расширение pg_dirty_hands, в котором мы будем собирать различные хаки, которые можно назвать «фол последней надежды».

Мастер-класс: продвинутый анализ пространственных данных с помощью PostgreSQL, PostGIS и Python

На мастер-классе будут рассмотрены: продвинутый анализ пространственных данных на чистом PostGIS, включая новейшие функции PostGIS; приведение в соответствие разных типов данных в PostgreSQL и Python (массивы в NumPy, таблицы в Pandas); секреты эффективной работы с инструментами и средами обработки данных (Jupyter, dataviz и др.); дальнейшее развитие с помощью GeoDataScience, библиотек и фреймворков Python, сочетаемых с PostgreSQL/PostGIS, включая технологии машинного и глубокого обучения.

Docker, PostgreSQL, Продуктив ....

Я бы хотел поделиться наработками в части использования PostgreSQL в докерезированных средах, рассказать, с какими особенностями вам придется столкнуться и какие дополнительные инструменты для этого понадобятся.

• Какие проблемы решает Docker для PostgreSQL, например PostgreSQLPro.9.6
• Как работать команде ИТ в условиях использования Docker на разработческих, приемочных и продуктивных контурах
  • Использование хранилища образов и серверов сборок для тестирования самого образа
• С чем придется столкнуться в продуктиве
  • В части сетевой активности
  • Организации персистентных хранилищ для Docker
  • Дополнительных служб и сервисов
  • В части балансировки и отказоустойчивости
• Как запустить у себя приложения, использующие PostgreSQL, такие как:
  • SonarQube
  • Gitlab
  • База 1С

Давайте отключим vacuum?!

Такой призыв часто возникает, когда в PostgreSQL возникают проблемы, и главным подозреваемым оказывается vacuum. По опыту, многие наступают на эти грабли, и мне с коллегам по Data Egret нередко приходится разгребать последствия, так как потом всё становится ещё хуже. Но если обратить внимание на сам vacuum, то, пожалуй, нет такого человека, который бы использовал Postgres, и при этом ничего не знал про вакуум. Ведь история вакуума начинается относительно давно, и в интернете можно найти массу как старых, так и новых постов про вакуум, объемные дискуссии в списках рассылки. Несмотря на то, что тема вакуума подробно описана в официальной документации к PostgreSQL, новые посты и новые дискуссии будут появляться и дальше. Возможно, поэтому с вакуумом связано очень много мифов, баек, страшилок и заблуждений. Между тем, вакуум является одним из важнейших компонентов PostgreSQL, и его работа напрямую сказывается на производительности. В одном докладе невозможно рассказать про вакуум абсолютно всё, но я бы хотел раскрыть ключевые моменты, связанные с вакуумом, такие как его внутреннее устройство, основные подходы к его настройке, наблюдение за производительностью, мониторинг, и что делать в случае, когда вакуум - главный подозреваемый во всех бедах. Ну и, конечно же, хочется развеять распространенные мифы и заблуждения, связанные с вакуумом.