PostgreSQL *

Дополняем EXPLAIN Postgres'a информацией об использованной статистике.

Незадолго до код-фриза PostgreSQL 18, Роберт Хаас закомитил возможность, разрешающую внешним модулям добавлять в EXPLAIN дополнительную информацию.

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

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

В список опций EXPLAIN был добавлен параметр STAT, принимающий булевы значения ON/OFF. Если он включён, то в конец эксплейна будет вставляться информация об использованной статистике: наличии MCV, гистограммы, количестве элементов в них. А также значения stadistinct, stanullfrac и stawidth.

Зачем это нужно? - спросите вы. Ведь набор статистик прямо следует из списка выражений, участвующих в запросе? Разве нельзя понять, какая статистика была непосредственно использована, заглянув в код cost-model того или иного вида выражения?

Можно, но этого не всегда достаточно. Мы знаем алгоритмы, но обычно нам недоступны данные. Поэтому мы не можем с уверенностью определить, какие конкретно статистики есть в pg_statistic по конкретной колонке и что конкретно было доступно бэкенду на момент эстимации.
Посмотрим на пример:

CREATE TABLE sc_a(x integer, y text);
INSERT INTO sc_a(x,y) (
SELECT gs, 'abc' || gs%10 FROM generate_series(1,100) AS gs);
VACUUM ANALYZE sc_a;
LOAD 'pg_index_stats';

EXPLAIN (COSTS OFF, STAT ON)
SELECT * FROM sc_a s1 JOIN sc_a s2 ON true
WHERE s1.x=1 AND s2.y LIKE 'a';

Nested Loop
-> Seq Scan on sc_a s1
Filter: (x = 1)
-> Seq Scan on sc_a s2
Filter: (y ~~ 'a'::text)
Statistics:
"s2.y: 1 times, stats: {
MCV: 10 values, Correlation,
ndistinct: 10.0000, nullfrac: 0.0000, width: 5 }
"s1.x: 1 times, stats: {
Histogram: 0 values, Correlation,
ndistinct: -1.0000, nullfrac: 0.0000, width: 4 }

Здесь можно увидеть, что была использована статистика по колонкам s1.x и s2.y.
При этом, у нас всего десять MCV значений по y, а по х MCV статистика отсутствует вовсе; гистограмма вроде есть, но нулевой длины. И никаких нуллов в обеих колонках.

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

Для отслеживания использованной статистики здесь был использован get_relation_stats_hook. Было бы полезно знать также, используется ли в планировании расширенная статистика, однако она находится слишком глубоко в ядре, и текущий набор хуков здесь никак не поможет.

А какие вы видите варианты применения возможностей расширения вывода эксплейна? Насколько в действительности безобидна даже такая ограниченная информация?

THE END.
12 апреля 2025, аэропорт "Шереметьево"

В начале 2024 года, в условиях активного импортозамещения и опасений возможных принудительных мер со стороны властей по переходу на отечественное ПО, мы начали искать альтернативные решения. Основываясь на опыте использования 1С, которое активно применяется в России, и после изучения материалов Гилева, мы решили рассмотреть PostgresPro Ent.

Проведя базовые тесты, нас устроила его функциональность, встроенная кластеризация BiHa PostgresPro Ent и административная панель PPEM. Все выглядело красиво и удобно. В итоге было принято решение закупить лицензии на PostgresPro Ent для двух серверов и развернуть на них часть баз 1С.

Развертывание прошло быстро и без значительных затруднений. Мы создали несколько инстансов для удобства восстановления, так как в отличие от MSSQL, в Postgres нельзя работать с резервными копиями отдельных баз данных без риска потери данных, а только с инстансом целиком.

В процессе эксплуатации выявились некоторые неприятные особенности. В частности, очень долгое резервное копирование с использованием pg_probackup. База 1С на MS SQL, объемом около 100 ГБ, копируется на сервер резервного копирования за 5-10 минут, в то время как аналогичная база на PostgresPro Enterprise требует более 2 часов. Многие могут предложить использовать более мощное оборудование или смотреть в сторону инкрементальных бэкапов (в плане обслуживания MSSQL мы используем как полные таки и инкрементальные). Но проблема заключается в самой логике работы pg_probackup, которая не позволяет сразу архивировать все файлы в один архив и далее работать уже с ними, а фактически учитывая структуру базы 1С там не одна тысяча мелких файлов которые очень "замечательно" копируются по сети, даже 10GBps не изменяет ситуацию. Также возникло множество мелких вопросов, требующих дополнительных компетенций, но пути решения были найдены, хотя и не всегда оптимальные. Вывод: PostgresPro требуется значительного много времени что бы догнать MS SQL в удобстве использования и обслуживания.

Однако главная особенность PostgresPro Enterprise заключается в следующем: при покупке бессрочной лицензии PostgresPro Enterprise, после окончания базовой подписки на техническую поддержку, вы не можете использовать ПО как вам хочется. Вы становитесь привязанными к тому оборудованию, на которое было установлено ПО (вспомним OEM лицензии от MicroSoft), и ваша бессрочная лицензия фактически превращается в лицензию по подписке. Этот факт выяснился через год после покупки, когда мы решили заменить серверы на более новые. Доступ к репозиторию уже был закрыт, так как закончился срок базовой техподдержки. Обращения в техническую поддержку не дали результатов: ответ сводился к предложению купить подписку на техническую поддержку или отказаться от использования ПО.

Таким образом, могу посоветовать: тщательно взвесить все за и против перед переходом на отечественное ПО, чтобы избежать подобных проблем.

p.s. Если у администрации ресурса возникнут сомнения в правдивости этого поста, могу предоставить номера обращений и даже предоставить скрины ответов PostgresPro Enterprise.

upd: Сравнение скорости создания резервных копий на MSSQL и PostgresPro производилось на аналогичных лезвиях в одной и той-же корзине, бэкапы льются в одно и то-же хранилище.

upd2: Покупая MSSQL вы имеете "вечный" доступ к загрузке дистрибутива, обновления в в рамках релиза, обновления безопасности до конца времени поддержки данной версии и так далее, в случае с PostgresPro без наличии активного сертификата на тп вы не имеете ничего.

Расскажем как эффективно работать с большими таблицами в PostgreSQL и упростить задачи администрирования на онлайн-митапе.

25 марта в 11:00 приглашаем на бесплатный онлайн-митап «PGMeetup: Механизмы секционирования больших таблиц». Это вторая встреча из цикла «Работа с данными в Postgres Pro Enterprise», и она посвящена одной из важных тем для любого DBA, работающего с большими объемами данных – секционированию таблиц.

Чем этот вебинар будет полезен именно администратору баз данных?

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

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

• Разберётесь в возможностях секционирования Postgres Pro, включая декларативное секционирование и автоматизацию с помощью pgpro_autopart. Повысьте свою квалификацию и добавьте ценный навык в свой арсенал.

• Получите практические знания о различных вариантах секционирования (hash, range, list), сценариях их применения и ограничениях. Применяйте проверенные решения в своей работе.

• Выясните, как планировщик запросов Postgres Pro взаимодействует с секционированными таблицами, чтобы вы могли максимально эффективно использовать этот механизм.

Митап проведет Владимир Пудовченко, технический консультант Postgres Professional, эксперт с многолетним опытом работы с Postgres Pro. 

Когда: 25 марта в 11:00 (онлайн, участие бесплатное по предварительной регистрации).

Формат: онлайн-трансляция на платформе PGConf (после мероприятия запись будет доступна).

Будет интересно и полезно администраторам баз данных, разработчикам и всем, кто работает с PostgreSQL.

Обновили курс DBA2 «Администрирование PostgreSQL 16. Настройка и мониторинг»

Компания Postgres Professional выпустила обновление курса DBA2 «Администрирование PostgreSQL 16. Настройка и мониторинг». Переработку и актуализацию материалов выполнили специалисты отдела образования Игорь Гнатюк и Илья Баштанов.

Обновлённая версия курса учитывает возможности, появившиеся в PostgreSQL 14, 15 и 16. Ряд тем был переработан, чтобы лучше отражать современные функции и возможности СУБД.

Этот курс – логичное продолжение DBA1. Если вы уже знакомы с основами PostgreSQL и Unix, то DBA2 – это следующий шаг. Он позволяет получить навыки, необходимые для:

• тонкой настройки конфигурационных параметров с пониманием внутренней организации сервера;

• эффективного мониторинга сервера с дальнейшей итеративной настройкой;

• работы с параметрами, связанными с локализацией, управления расширениями и обновления сервера.

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

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

Курс уже находится в свободном доступе:

https://postgrespro.ru/education/courses/DBA2

5 утра, чашка кофе, такси, самолёт ...

#PostgresPro #pgproday спасибо за интересный и познавательный день. Новые знакомства, новые знания и новые возможности. Организация мероприятий как всегда на высшем уровне.

До встречи на Pg Conf 2025.

PGConf.Russia 2025 ждёт доклады

Мы ищем тех, кто горит PostgreSQL так же, как и мы. Если вы администратор баз данных, разработчик, архитектор или DevOps-инженер, и в вашей работе PostgreSQL играет важную роль – нам есть что обсудить.

PGConf.Russia 2025 пройдёт 31 марта – 1 апреля в Центре международной торговли в Москве и онлайн. 

О чём рассказать?

Возможные темы для докладов на PGConf.Russia 2025:  

• Практический опыт администрирования PostgreSQL, оптимизация производительности и автоматизация задач.

• Архитектурные решения для обеспечения отказоустойчивости и масштабирования PostgreSQL: резервное копирование, восстановление, кластеризация, шардирование.

• Инструменты и методики эффективной миграции на PostgreSQL с других СУБД или устаревших версий.

• Опыт использования новых возможностей и расширений PostgreSQL, их применение и перспективы.

Почему сто́ит выступить?

PGConf.Russia 2025 — это:

• Большая аудитория. 1 500+ увлечённых профессионалов, готовых учиться, обмениваться опытом и задавать каверзные вопросы. 

• Признание и уважение. Ваш опыт ценен для сообщества. Выступление на PGConf.Russia – это возможность заявить о себе, повысить профессиональный статус и получить заслуженное признание.

• Бесплатное участие и размещение. Мы ценим вклад спикеров. Для докладчиков участие в конференции и размещение – за наш счёт.

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

Как подать заявку?

До 23 февраля 2025 года зайдите на сайт PGConf.Russia 2025 и нажмите кнопку «Подать доклад». Заполните название и аннотацию доклада, выберите формат, если нужно, оставьте дополнительный комментарий для программного комитета.

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

И ещё раз о внешних ключах

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

Мой тестовый пример (все имена реальных объектов заменены, планы и цифры реальные). Выполняю 3 варианта валидации FK c разными настройками сессии, план исполнения смотрю через расширение pg_query_state.

Исполнение "по умолчанию" выбирается merge join.
ALTER TABLE child_t VALIDATE CONSTRAINT fk_child_parent;

select plan from pg_query_state(1483434);
                                                          plan
------------------------------------------------------------------------------------------------------------------------
 Merge Anti Join (Current loop: actual rows=0, loop number=1)                                                          +
   Merge Cond: (fk.entity_egrn_id = pk.id)                                                                             +
   ->  Index Only Scan using child_t_idx1 on child_t fk (Current loop: actual rows=1, loop number=1)    +
         Index Cond: (entity_egrn_id IS NOT NULL)                                                                      +
         Heap Fetches: 1                                                                                               +
   ->  Index Only Scan using parent_t_pkey on parent_t pk (Current loop: actual rows=113215, loop number=1)+
         Heap Fetches: 113215
(1 row)

SET enable_mergejoin TO false;
ALTER TABLE child_t VALIDATE CONSTRAINT fk_child_parent;

 select plan from pg_query_state(1483434);
                                             plan
-----------------------------------------------------------------------------------------------
 Hash Anti Join (Current loop: actual rows=0, loop number=1)                                  +
   Hash Cond: (fk.entity_egrn_id = pk.id)                                                     +
   ->  Seq Scan on child_t fk (Current loop: actual rows=1, loop number=1)            +
         Filter: (entity_id IS NOT NULL)                                                 +
   ->  Hash (Current loop: actual rows=0, loop number=1)                                      +
         Buckets: 67108864  Batches: 8  Memory Usage: 165802kB                                +
         ->  Seq Scan on parent_t pk (Current loop: actual rows=33979819, loop number=1)

SET enable_hashjoin TO false;
SET enable_mergejoin TO false;
ALTER TABLE child_t VALIDATE CONSTRAINT fk_child_parent;

select plan from pg_query_state(1483434);
                                               plan
---------------------------------------------------------------------------------------------------
 Nested Loop Anti Join (Current loop: actual rows=0, loop number=1)                               +
   ->  Seq Scan on child_t fk (Current loop: actual rows=329042, loop number=1)           +
         Filter: (entity_id IS NOT NULL)                                                     +
   ->  Index Only Scan using parent_t_pkey on parent_t pk (actual rows=1 loops=329041)+
         Index Cond: (id = fk.entity_id)                                                     +
         Heap Fetches: 329041

Почему всё это может быть важно:
1. Вы банально могли что-то делать в своей сессии и манипулировать её состоянием, например, "форсить" вычитку через Nested Loop, а затем запустить построение/валидацию FK на громадных таблицах.
2. По каким-то причинам PG выбрал неподходящий план, и вы знаете, что другой способ будет наверняка лучше :)

И ещё раз о внешних ключах

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

Представлю мой тестовый пример (все имена реальных объектов заменены, планы и цифры реальные). Выполняю 3 варианта валидации FK c разными настройками сессии, план исполнения смотрю через расширение pg_query_state.

Исполнение по умолчанию выбирается merge join.
ALTER TABLE child_t VALIDATE CONSTRAINT fk_child_parent;

select plan from pg_query_state(1483434);
                                                          plan
------------------------------------------------------------------------------------------------------------------------
 Merge Anti Join (Current loop: actual rows=0, loop number=1)                                                          +
   Merge Cond: (fk.entity_id = pk.id)                                                                             +
   ->  Index Only Scan using child_t_idx1 on child_t fk (Current loop: actual rows=1, loop number=1)    +
         Index Cond: (entity_id IS NOT NULL)                                                                      +
         Heap Fetches: 1                                                                                               +
   ->  Index Only Scan using parent_t_pkey on parent_t pk (Current loop: actual rows=113215, loop number=1)+
         Heap Fetches: 113215
(1 row)

SET enable_mergejoin TO false;
ALTER TABLE child_t VALIDATE CONSTRAINT fk_child_parent;

 select plan from pg_query_state(1483434);
                                             plan
-----------------------------------------------------------------------------------------------
 Hash Anti Join (Current loop: actual rows=0, loop number=1)                                  +
   Hash Cond: (fk.entity_egrn_id = pk.id)                                                     +
   ->  Seq Scan on child_t fk (Current loop: actual rows=1, loop number=1)            +
         Filter: (entity_id IS NOT NULL)                                                 +
   ->  Hash (Current loop: actual rows=0, loop number=1)                                      +
         Buckets: 67108864  Batches: 8  Memory Usage: 165802kB                                +
         ->  Seq Scan on parent_t pk (Current loop: actual rows=33979819, loop number=1)

SET enable_hashjoin TO false;
SET enable_mergejoin TO false;
ALTER TABLE child_t VALIDATE CONSTRAINT fk_child_parent;

select plan from pg_query_state(1483434);
                                               plan
---------------------------------------------------------------------------------------------------
 Nested Loop Anti Join (Current loop: actual rows=0, loop number=1)                               +
   ->  Seq Scan on child_t fk (Current loop: actual rows=329042, loop number=1)           +
         Filter: (entity_id IS NOT NULL)                                                     +
   ->  Index Only Scan using parent_t_pkey on parent_t pk (actual rows=1 loops=329041)+
         Index Cond: (id = fk.entity_id)                                                     +
         Heap Fetches: 329041

Почему всё это может быть важно:
1. Вы банально могли что-то делать в своей сессии и манипулировать её состоянием, например "форсить" вычитку через Nested Loop, а затем запустить построение/валидацию FK на громадных таблицах.
2. По каким-то причинам PG выбрал неподходящий план, и вы знаете, что другой способ будет наверняка лучше :).

Module Info в бинарных файлах модулей Postgres

Если вы мэйнтейнер расширения Postgres, модуля без UI или просто пользуетесь некоторым набором расширений на регулярной основе, то ваше мнение будет здесь очень полезно.

Каждый модуль, который вы попытаетесь загрузить в Postgres, в обязательном порядке содержит в своём теле информацию о версии ядра, для которого оно было собрано и параметрах его сборки. Обоснование необходимости этого можно найти в треде с обсуждением этой фичи, однако идея прозрачна: это сделано для того, чтобы предотвратить ошибку загрузки несовместимого модуля и связанные с этим нестабильности в работе инстанса СУБД.

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

Идея родилась во время поддержки расширения, которое имело достаточно стабильный UI и часто изменяющийся код библиотеки: для ответов на вопросы клиентов чтобы воспроизвести ситуацию на стенде требовалось знать конкретную версию кода, для чего приходилось вводить в релизную политику правило именования библиотек и добавлять специальную экспортируемую константу в код модуля. Однако это не является достаточной гарантией определения версии и усложняет рабочий процесс при поддержке большого количества расширений, поставляемых из разных источников.

Гораздо проще было бы, если бы ядро содержало в себе фунцию, например, module_info(module_name), которая позволяла бы изнутри СУБД (например, в консоли psql) определить полный путь и имя файла, содержащего искомый модуль. Более того, при наличии двух версий одного модуля в ядре (да, бывает и такое!), мы получаем возможность обнаруживать потенциальные конфликты. При этом, появляется возможность автоматизировать обнаружение модулей и их версий в системе другими модулями - да, я ненавижу использовать функцию SerializeLibraryState и другие грязные хаки для этой цели!

Ещё одна причина (уже глубоко техническая) связана с тем, что теперь (с апреля 2024 г.) расширения для текущей и последующих версий Postgres могут использовать dynamic shared memory (DSM) без необходимости быть загружаемыми при старте инстанса. Это открыло путь разработки легковесных модулей, которые могут быть загружены динамически в каждом отдельном бэкенде. Помимо производительности преимущество здесь в том, что появляется возможность реализовать технику онлайн-апгрейда расширения - установив новую версию модуля в системе под другим именем и загружая такую новую версию во вновь стартующих бэкендах мы имеем обновление функциональности на лету, без остановки инстанса! - по крайней мере, у меня в голове вырисовывается именно такой сценарий.

С другой стороны, проект omnigres (автор Yurii Rashkovskii) также пришёл к идее версионирования модулей, хотя и делает это внешним, по отношению к ядру, путём.

Все вышесказанные соображения привели меня к необходимости разработать обобщённый патч в ядро Postgres, который предоставляет модулям и расширениям такую возможность. Код сделан на основании опыта поддержки и эксплуатации расширений и включает в себя также наработки проекта omnigres. Ветка с кодом доступна на GitHub.

Перед тем, как начинать долгий путь обсуждения кода в hackers mailing list будет очень полезно аккумулировать опыт и мнения других разработчиков и мэйнтейнеров расширений Postgres. Нужна ли такая фича? Должна ли она быть опциональной или обязательной? Какая информация о модуле нужна (или просто будет полезна) в ваших инсталляциях?

Предлагайте ваши идеи и делитесь своим мнением в комментах, или в github-дискуссии сообщества PGEDC разработчиков расширений Postgres. Каждое мнение имеет ценность!

Раз в год-два мне приходится вспоминать, что Python — не C++.

В этот раз я наткнулся на случай, когда отформатировать и склеить колонки результата запроса на стороне PostgreSQL и распарсить Python-ом оказалось эффективнее, чем запрашивать колонки как отдельные значения.

Конкретнее, при переходе от этого запроса:

SELECT * FROM o_relations ORDER BY id DESC LIMIT %(limit)s

к этому:

SELECT CONCAT(entry_id::text, '|', tag_id::text) AS ids FROM o_relations ORDER BY id DESC LIMIT %(limit)s

скорость извлечения данных увеличилась примерно в 4 раза.

Причиной тому тяжёлая конвертация данных из формата С в формат Python внутри Psycopg.

За подробностями можно сходить ко мне в блог: https://tiendil.org/ru/posts/fun-case-of-speeding-up-data-retrieval-with-psycopg

В блокнотик. Мысли на подумать , проверить на практике . И план на сегодня.

Условия остановки стресс-теста , по условиям AND / OR:

1. Снижение метрики производительности на X%

2. Увеличение среднего времени отклика на T%

3. Среднее время отклика >= TMax

4. RAM utilization >= R%

5. CPU utilization >= C% . (Только OR)

6. Общее время стресс теста

7. Максимальное количество активных сессий >= AMax

8. Какое то дополнительное условие ?

А тем временем, постепенно, складывается вполне себе стройная концепция применения мат. статистики и методов оптимизации при сопровождении СУБД.

1) Оптимизация конфигурационных параметров СУБД при разворачивании нового кластера PostgreSQL - метод покоординатного спуска .

2) Стресс тестирование - определение предельной нагрузки на инфраструктуру СУБД при выполнении тестового сценария.

3) Бенчмарк - фиксация базовых показателей производительности

4) Передача СУБД в разработку приложения

5) Нагрузочное тестирование и корреляционный анализ производительности в процессе разработки ПО.

6) Передача СУБД в опытную эксплуатацию

7) Стресс тестирование - определение предельной нагрузки на инфраструктуру СУБД при выполнении продуктивного сценария . Протоколирование значений для использования в качестве граничных при мониторинге .

8) Нагрузочное тестирование и корреляционный анализ производительности в процессе тестирования . Протоколирование значений для использования в качестве граничных при мониторинге .

9) Передача СУБД в промышленную эксплуатацию. Протоколирование граничных значений для мониторинга .

10) Корреляционный анализ производительности СУБД. Управление инцидентами , проблемами , изменениями .

Цели ясны, задачи определены . За работу товарищи!

Хорошо, когда идёшь по маршруту с заранее заданными контрольными точками.

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

Репликация делается асинхронно — данные записываются на основной сервер и только после этого отправляются на реплики.

В кластер можно объединить 3 или 5 серверов. Доступные для этого регионы: Москва, Санкт-Петербург и Нидерланды.

Стоимость репликации равна стоимости конфигурации одного сервера, умноженной на 3 или 5.

Создать PostgreSQL с репликацией → 

По итогам очередных экспериментов , в ходе отработки методологии стресс тестирования СУБД , в принципе можно было бы подготовить ещё одну статью на тему "Влияние CPU Utilization = 100% на производительность СУБД".

Но, учитывая негативный (слитие кармы) опыт предыдущей статьи на аналогичную тему - нет никакого практического смысла и пользы - делится результатами наблюдений и экспериментов .

Так, что, просто в заметки на память, в качестве промежуточного личного итога:

Событие "предельная утилизация CPU" при отсутствии события "деградации производительности СУБД" - не является стартовым событием для создания инцидента .

А почтовое оповещение мониторинга "CPU High Utilization" , я давно уже фильтрую.

По итогам анализа результатов экспериментов по стресс тестированию, наверняка будет подготовлена метрика "Performance is OK"(есть пара идей) и вот по ней и будет настроено оповещение и создание инцидента по производительности СУБД.

Чем дольше копаю тему статистического анализа производительности СУБД, тем больше удивляюсь - почему никто не занимался/не занимается использованием математических методов в DBA ? Статей и материалов практически - нет. По performance engineering - можно найти, по DBA в общем то тишина.

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

Это же так просто и в общем то лежит на поверхности - сделал изменение , собери статистику влияния и оцени характер полученных результатов по совокупности опытов. Нужно подчеркнуть - не картинки, не "кажется" , "наверное" , "скорее всего", "может быть" , а цифры. И цифры взятые не с потолка , а рассчитанные математически. И даже не надо ничего нового придумывать и изобретать - медиана, мода , стандартное отклонение , дисперсия , корреляция - 3й курс КАИ, если не ошибаюсь. Вполне достаточно , для получения объективных результатов анализа, а не гаданий и шаманских танцев с бубнами.

Почему DBA не используют математику ? Риторический вопрос ....

Однако, с бенчмарками, всё совсем не просто .

По умолчанию pgbench тестирует сценарий, примерно соответствующий TPC-B, который состоит из пяти команд SELECT, UPDATE и INSERT в одной транзакции.
https://postgrespro.ru/docs/enterprise/16/pgbench

В 1995 году TPC-A и TPC-B были признаны несостоятельными, и появился более совершенный TPC-C.
https://ibs.ru/media/etalonnye-testy-subd-chto-bylo-chto-stalo-chto-budet/

2 варианта дальнейших действий:

1. Продолжать использовать pgbench.

2. Искать реализации TPC-C и/или более новых сценариев.

Вариант самостоятельной реализации TPC-C , в виду ограниченности ресурсов - не рассматривается .

PostgreSQL 17 уже в Облаке Рег.ру

Мы обновили DBaaS, добавив в него две версии PostgreSQL: 16 и 17.  PostgreSQL 17 упрощает работу с большими нагрузками и улучшает безопасность данных. Теперь ваши проекты будут работать еще быстрее и стабильнее.

Официальный релиз PostgreSQL 17 состоялся 26 сентября 2024 года. 

Ключевые моменты версии: 

• Повышена производительность

  Обработка данных стала более быстрой и надежной, особенно под высокой нагрузкой.

• Ускорена работа с массовыми данными

  Новые алгоритмы обработки позволяют значительно сократить время загрузки и экспорта больших объемов информации.

• Упрощенная работа с JSON

  Новая команда SQL/JSON JSON_TABLE делает запросы к данным в формате JSON более гибкими и удобными.

• Улучшены механизмы логической репликации

  Это упрощает управление данными в условиях высокой доступности и делает процесс обновления на новые версии более эффективным.

Попробуйте PostgreSQL 17 в Облаке Рег.ру!

Мысли вслух.

Размещать в хабе "PostgreSQL" статьи на тему статистического анализа - не имеет практического смысла. Перенес в хаб "Математика". Может быть от математиков удастся получить более-менее полезную обратную связь. Есть надежда, что хоть, что-то не на эмоциях и IMHO-х , а на цифрах и фактах , все таки получится дождаться в комментариях. Поживём увидим.

P.S. Зарегистрировался на математических форумах . Может там ответят ....

P.P.S. Ответили и на математическом форуме и в комментариях к посту в хабе "Математика". Стиль комментариев , по сравнению с хабом "PostgreSQL" различается принципиально и очень кардинально. Все следующие статьи и посты будут размещены только в хабе "Математика" и на математических форумах. Эх, сколько времени было потрачено на пустой флейм с ремесленниками или просто флудерами :-( Надо было сразу , тему статистического анализа начинать обсуждать с математиками, а не с DBA.

Update.

Математики - читают больше.

Сергей Ким, руководитель команды разработки WMS и активный пользователь Яндекс Лавки, рассказал, про внутренний мир Лавок. 

Обсудили: 

• как Яндекс управляет лавками, узнаёт о товарных остатках и рассчитывает время курьеров, чтобы вовремя доставлять все заказы; 

• о чём можно узнать с помощью проактивных пушей изменений и периодического пула всего сразу;

• как перекладывать JSON с минимальным лагом. 

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

Интересно , возможно ли определить объем данных ( количество строк * средний размер строк ), сформированных SQL запросом ?

Количество строк определяется тривиально . Но как определить общий размер результирующих строк , идеально конечно мат.ожидание и стандартное отклонение? Сдается , мне , что - никак. По крайней мере, простой гуглеж ничего полезного не дал. К сожалению.

Но это, как раз, тот случай когда хотелось бы ошибиться.