В одной из предыдущих статей я описывал проблемы, которые возникают при работе с временными таблицами. Тогда я вкратце описывал, почему нам приходится их так часто использовать. В частности, одной из причин была неправильная работа планировщика запросов в PostgreSQL. Многие из проблем планировщика запросов (и не только PostgreSQL) были также описаны в статье Почему не SQL. В этой статье я покажу достаточно простой и часто используемый случай, когда планировщик ошибается, что может приводить к значительному росту потребления ресурсов. 

Проблема воспроизводится на последней стабильной на данный момент версии PostgreSQL - 16.2. При этом используются стандартные настройки PostgreSQL. Я пробовал менять разные настройки, но мне не удалось добиться правильного плана в общем случае, поскольку в данном случае проблема скорее логическая, а не в определении стоимости вычислений. Однако, каждый может легко воспроизвести эту ситуацию локально и попробовать поиграться с настройками. 

Рассмотрим простую доменную логику, в которой есть документы и их строки. Для каждой строки вводится сумма. Строки лежат в отдельной таблице и ссылаются на документ :

Павел Труханов, "Мониторинг Postgres по USE и RED"

Есть две методологии перформанс мониторинга: USE (Utilization, Saturation, Errors) Брендана Грегга и RED (Requests, Errors, Durations) от Тома Уилки. В докладе я хочу рассказать о том, как мы на них ориентировались и продолжаем ориентироваться, когда реализуем мониторинг Postgres в okmeter.io.

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

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

Хабр, привет! Сегодня обсудим, как проверять много гипотез в одном эксперименте. Разберёмся, почему растут вероятности ошибок. Познакомимся с метриками множественного тестирования и поправками, которые позволяют их контролировать. Узнаем, как оценить необходимый размер групп и повысить чувствительность.

Карта видимости - это достаточно простой механизм в СУБД PostgreSQL, но даже он имеет множество интересных тайн, если погрузиться в детали реализации.

В этой статье мы выясним:

1. Какие особенности есть у механизма сбрасывания и установки бита полной видимости.

2. Как Index only scan использует бит полной видимости.

3. Зачем записывать информацию об изменении карты видимости в WAL.

4. Каким образом карта видимости участвует в оптимизации предвыборки Bitmap scan.

5. Зачем механизму оценки селективности нужна карта видимости.

Введение

Добрый день!

Это моя первая статья на Хабре. Работаю опсом в международной компании. Решил чуть удариться в ностальгию. :)

Тут есть несколько статей про Фидонет. Там много полезной информации, но с тезисом, что Фидо убило себя само, когда не перешло на http/web формат я не согласен, ибо сам являлся активным участником (не пойнт, нода) тех событий.

То было время романтического программирования интрух на асме, mod, stm, s3m-плейеров на паскаль+асм и т.п… В Фидо были такие же (в основном) убеждённые в правильности своего выбора профессии IT-шники.

Привет, меня зовут Владимир Сердюк. Я основатель компании Софтпоинт и этой статьей хочу открыть цикл, посвященный распределенным кластерам СУБД с возможностью равномерного распределения нагрузки по всем его серверам.

Идеи создания распределенного вычислительного кластера СУБД (далее РВК) посещали меня достаточно давно. Если упрощенно описать, то программное обеспечение РВК позволяет объединить множество серверов в один суперсервер (кластер), осуществляющий равномерную балансировку всех запросов между отдельными серверами. При этом для приложения, которое работает на РВК все будет выглядеть как будто оно работает с одним сервером и одной базой данных (далее БД), это будут не разрозненные базы данных на распределенных серверах, а как будто одна виртуальная. Все сетевые протоколы, репликационные обмены, прокси-перенаправления будут скрыты внутри РВК. При этом будут эффективно и равномерно использоваться все ресурсы распределенных серверов, в частности, оперативная память и процессорное время.

В этой статье мы погрузимся в мир теории очередей и исследуем, как её принципы могут быть применены для оптимизации опросов в сфере клиентского сервиса. Мы изучим, как понимание поведения клиентов в условиях ожидания и выбора может помочь в улучшении качества и эффективности опросов, проводимых компаниями.

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

Это перевод статьи профессора Бертрана Мейера из блога Communications of the ACM.

Статья относительно недавняя (по сравнению с предыдущим переводом).

Кроме того, что Бертран Мейер известен большинству специалистов как создатель языка программирования Eiffel и идей контрактного программирования (design by contract), он является почетным доктором и заведующим кафедрой ИТМО, преподает в университете Иннополис. И прекрасно владеет русским языком. ;)

Вы приходите на остановку. Написано, что автобус ходит каждые 10 минут. Засекаете время… Наконец, через 11 минут приходит автобус и мысль: почему мне всегда не везёт?

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

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

Целевая точка восстановления (RPO) и целевое время восстановления (RTO) дают организациям возможность определять допустимые потери данных и диапазон времени простоя систем. Эти метрики являются основными при разработке планов по хранению данных, резервному копированию и аварийному восстановлению, обеспечению эксплуатационной устойчивости, а также непрерывности бизнеса.

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

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

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

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