Если вам неудержимо хочется использовать оборудование из музея для современной разработки — статья специально для вас.

СУБД Postgres Pro – сложный механизм, который можно гибко настраивать под конкретный тип нагрузки. Для этого в нём имеется множество параметров и инструментов. Например, одним из главных потребителей ресурсов CPU является оптимизатор/планировщик запросов, который отвечает за построение оптимального плана выполнения. Существует большое количество параметров, которые прямо или косвенно влияют на работу планировщика, но к их изменению надо подходить очень осторожно, т. к. возможен обратный эффект. Например, параметры _collapse_limit могут и помочь оптимизатору рассмотреть большее количество вариантов планов, и негативно повлиять на время планирования.

Сегодня я расскажу, как мы решали реальную проблему производительности и высокой (> 90%) утилизации ресурсов CPU на промышленном «боевом» сервере с СУБД Postgres Pro Enterprise 15, обслуживающем запросы бизнес-приложения, какие для этого использовали инструменты и что мы изменили в настройках СУБД.

Продолжаем делиться полезными инсайтами с наших корпоративных митапов. Сегодняшний спикер, старший бэкенд-разработчик Factory5 Роман Гордиенко рассказывает об основных понятиях реляционных баз данных и о том, как использовать индексы в PostgreSQL. Информация будет полезна всем, кто работает с реляционными базами данных или планирует это делать в будущем.

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

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

Эти фичи уже не раз выручали меня в сложных проектах, и я уверен, что они станут надежными помощниками и в вашей разработке.

Сложилось так исторически, что мы долго не обновляли PostgreSQL и застряли на версии 12. Но пришло время обновлять зависимости проекта и оказалось, что Django 5.1 версию 12 PostgreSQL уже не поддерживает и это мотивировало меня провести обновление до новейшей 16 версии.

На момент написания у нас всё организовано достаточно просто — все необходимые компоненты запускаются в Docker-контейнерах через Docker Compose.

У меня было два варианта, как произвести миграцию:

Добрый день, коллеги! Как известно, компания "Postgres Professional" более не рекомендует использовать секционирование с использованием pg_pathman, а рекомендует использовать вместо него декларативное секционирование. Однако помимо синтаксического сахара и утилитарного кода по поддержке интервального (в стиле Oracle) секционирования, я обнаружил для себя ещё одну проблему в такой миграции (переходе). Надеюсь, коллеги из PGPro доработают декларативное секционирование к моменту окончательного выпиливания pg_pathman.

В продолжение серии статей об устройстве системы управления базами данных PostgreSQL (раз, два) смотрим, как ускорить выполнение запросов к базе данных с помощью индексов.

Привет, Хабр! Меня зовут Артур Титаев, я аналитик департамента проектирования и разработки IBS. Недавно наша команда занималась масштабным импортозамещением компонентов системы поддержки принятия решений для крупного российского заказчика. После переезда с Oracle и MySQL на PostgreSQL мы определили, что время выполнения SQL-запросов для показателей хозяйственно-экономической деятельности клиента в PostgreSQL заметно больше, чем время выполнения тех же запросов для тех же показателей в Oracle. Для «тяжелых» показателей разница во времени выполнения запроса могла достигать 20–30 минут. И это несмотря на то, что база данных Oracle не была проиндексированной!

Вопрос о применении индексов в PostgreSQL — особой структуры данных, которая ускоряет выборку из таблицы, — встал ребром, и я принялся за его изучение. Раньше мне доводилось сталкиваться только с простейшими индексами, так что на полноценное погружение в тему у меня ушло немало часов. Чтобы сэкономить вам время, я собрал ключевую теорию про индексирование в этой статье.

Кластеризация необходима для большинства СУБД уровня Enterprise. Есть много способов создать или развернуть кластер: от бесплатных до дорогих, от простых до сложных. У разных вендоров свои приоритеты: одни делают настройку кластера в пару кликов (как в MS SQL), другие фокусируются на надежности и функциональности (Oracle).

В мире СУБД на базе PostgreSQL на сторону которых всё активнее переходит российский IT, тоже есть свои кластерные инструменты и решения: как бесплатные и открытые Patroni, Stolon, pacemaker/corosync, так и проприетарные. Лидер по популярности среди открытых решений – Patroni. Сегодня я расскажу, почему настраивать кластеризацию на нем руками весело только первые пару раз. Поговорим об особенностях поддержки Patroni в Proxima DB, снижении порога входа для новичков и повторяемости конфигураций. 

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

Для начала определимся с общеизвестными вещами. Данные хранятся в таблицах, таблицы находятся в схемах, схемы, в свою очередь, в базах данных. Под данными я тут подразумеваю одну или несколько строк. В качестве примера будем рассматривать эталон критики, по моему личному мнению, цитаты Линуса Торвальдса.

Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

В первой части лекции мы узнали, что такое план выполнения запроса, как и зачем его читать (и почему это совсем непросто), и о каких проблемах с производительностью базы он может сигнализировать. В этой - разберем, что такое Seq Scan, Bitmap Heap Scan, Index Scan и почему Index Only Scan бывает нехорош.

Как обычно, для предпочитающих смотреть и слушать, а не читать - доступна видеозапись (часть 1, часть 2) и слайды.

Однажды нам нужно было уменьшить мастер кластера PostgreSQL по CPU и памяти. План был надёжный: дождаться низкой нагрузки на кластер, сменить мастер на одну из асинхронных реплик, переконфигурировать виртуальную машину с бывшим мастером и сделать switchover обратно. Казалось бы, что могло пойти не так?

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

Это вторая часть статьи, в которой мы разберем процессы очистки и перестроения индексов, журнал предзаписи с чекпоинтами, а также логирование.

Это третья часть статьи, в которой мы научимся работать с базами, ролями, консолью, а также политиками подключений.

Это четвертая часть статьи, в которой мы научимся работать с логическими и физическими резервными копиями, а также сравним алгоритмы сжатия.

Это пятая, заключительная часть статьи, в которой я скажу пару слов про расширения, мониторинг, а также подведу некоторые итоги по статье в целом.

Обычные последствия после получения оповещения мониторинга «CPU Utilization High» — все в панике, лихорадочные поиски причин, аварийная ситуация, конфколлы и т. д. и т. п. Всё, как положено для ИБД.

Однако, если посмотреть на ситуацию чуть подробнее, то выясняется, что всё не так печально, а даже совсем наоборот и причин для паники — никаких.

Задачи эксперимента

1) Оценить степень влияния регулярного выполнения vacuum/analyze на производительность СУБД.

2) Оценить степень влияния распухания таблицы на производительность СУБД.

Привет, Хабр!

Сегодня поговорим о том, как правильно настраивать автовакуумирование в PostgreSQL — одном из механизмов, который позволяет базе данных оставаться «в форме» и поддерживать производительность на должном уровне. Если неправильно подойти к настройке, можно столкнуться с деградацией скорости обработки запросов и внезапным ростом объема данных.

В мире управления базами данных от эффективного хранения больших объемов информации зависит оптимизация производительности и использования дискового пространства. В этой статье разберем основные методы сжатия данных в TOAST, их эволюцию, плюсы и минусы PGLZ и LZ4 и продемонстрируем базовую работу с TOAST в Postgres. В завершение обсудим, как данные с различными методами сжатия могут храниться в одной TOAST-таблице.