Эти материалы являются объектом авторского права и защищены законами РФ и международными соглашениями о защите авторских прав. Перед использованием материалов вы обязаны принять условия лицензионного договора на использование этих материалов, или же вы не имеете права использовать настоящие материалы

Авторская площадка "Наши орбиты" состоит из ряда тематических подразделов, являющихся моими лабораторными дневниками, содержащими записи за разное, иногда продолжительно отличающееся, время. Эти материалы призваны рассказать о прошедшем опыте, они никого ни к чему не призывают и совершенно не обязательно могут быть применимы кем-то ещё. Это только лишь истории о прошлом

Первый подход к снаряду. О реализации аналогичных Ораклу энтерпрайз функций СУБД Postgree SQL

Продолжаем отстраивать понятийную навигацию о возможностях СУБД Postgree SQL в сравнении с возможностями СУБД Oracle c горизонта инженера по эксплуатации, т.е администратора баз данных. Потому что у разработчиков совершенно точно будут свои горизонты и точкит важности. Изложенное выше является всего лишь первым "подходом к снаряду", нащупыванием векторов движения. Я конечно имею предвзятость и ожидания к любой альтернативной СУБД не меньшие, чем СУБД Oracle, которая у нас была и остается номер ОДИН в мире. Тем удивительнее наблюдать, что предвзятые ожидания к Postgree SQL сильно отличаются от реальности, и путь развития, пройденный Pg SQL позволяет вспомнить о возможностях групповой разработки и подходов Open Source, когда даже крупные разработкичи, такие, как компания ПостгресПРО, прилично отдают в сообщество, обогащая функционал СУБД. А коммерческие редакции уже местами дышат чемпиону в спину. В этой статье зафиксирую свои подходы, мысли и исследования в части общедоступной редакции СУБД и ее готовности к замещению Oracle

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

• собственно производительная работа СУБД с поддержкой эффективного многопользовательского режима, версионности чтения, возможностей обработки данных, реализации стандартов SQL, его расширений и процедурных языков
• функционал резервирования данных и сервиса в энтерпрайз режиме. Это и горячий бэкап без остановки сервиса, в т.ч. инкрементальный, и организачия физических стэндбаев, и иногда востребованные логические репликации
• сервисные возможности - выгрузки и перегрузки части объектов БД, пакетная загрузка данных. В Oracle это утилитф exp/imp, expdp/impdp, sqlloader
• накопление и анализ текущей и исторической статистики, в том числе в разрезе сессий, запросов, системы в целом, метрик работы различных подсистем СУБД. В Oracle это AWR, функции трассировки сессий и профилирования запросов
• возможности по настройке планов выполнения хинтами и фиксации планов ывполнения. В Oracle это хинты как таковые, а во второй части - SPM, profile, outline
• различные аналоги DBMS_ пакетов, использующихся в администрировании СУБД
• и далее менее значительное по списку

В части производительной работы у PgSQL всё неплохо. Стандарт SQL, расширения, различные процедурные языки, процедуры и функции, в т.ч. аналитические функции. Отдельные вызывает вопросы отсутствие в общедоступной версии автономных (вложенных) транзакций, пакетов, библиотечного кэша и пресловутый 32 битный счётчик LSN - аналог SCN в Oracle. Однако при анализе количества тиков на текущем месте службы выяснили, что лимита LSN тиков в 4 млрд. хватит на полтора месяца работы незавершённой транзакции, что востребовано на отчётных стэндбаях, открытых для чтения. Но транзакций такой протяженности я не встречал. Даже Standart Edition коммерческой PostgresPRO имеет ту же разрядность, которой может не хватить только для поистине гигантских скоростей изменений в БД. Пактеы действительно могут являться проблемой, т.к. в Оракле их основной смысл в разовом разборе и закреплении в библиотечном кэше. Однако это нужно тестировать, с учетом принудительного слияния запросов с разными литералами в фильтрах производительности вполне может хватить и без пакетов. В комерческой реализации СУБД от компании ПостгресПРО (PgPRO) пакеты эмулируются схемами, которые в PgSQL легковесны и не влекут перемещения объектов при изменении схемы. Этот момент требует отдельного изучения

Экспорт, импорт, загрузка, организация бэкапов рассмотрена в статье про бэкапы Промышленный режим горячего бэкапа в общедоступной версии есть, он мной для своих целей протестирован, но вот инкрементального нет. Зато он есть в свободно поставляемой компанией ПостгресПРО утилите pg_probackup, доступной и для свободной версии СУБД, которую утилиту и предстоит изучить и протестировать

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

Текущая и историческая статистика В PostgreeSQL есть система накопительной статистики, но она в чистом виде сильно уступает тому же Oracle AWR, настольно, что кажется - между ними непреодолимая пропасть. Здесь по совокупности факторов, а именно очень беглом знакомстве на курсе по PgSQL с документацией от PgPRO, прозвучавшей на одном из вебинаров мысли докладчика, что, мол, хотите функционал как в Оракле - ищите и тестируйте расширения, мне пришлось закопаться в документацию коммерческой реализации от Постгрес ПРО, и изучить, какие расширения поставляются в коммерческой редакции СУБД. И вот здесь выяснилось, что всё местами не так плохо, т.к. часть поставляемых в солидной коммерческой версии СУБД расширений доступна и в ванильной версии. Правда вторая часть, не менее востребованная - не поставляется свободно. Только за денежку. Итак, в СУБД PostgresSQL реализован механизм расширений, когда дополнительный функционал просто подключается без перекомпиляции исходников самой СУБД. А расширений мировое сообщество написало очень прилично. В первую очередь мы пройдемся по тому, что мне удалось нарыть, установить и немного изучить в части уже доступных для скачивания и установки расширений. Документация от Постгрес ПРО выступила тут как этакий гарант, что расширение не "фуфлыжное" и с ним можно иметь дело

Аналог ASH В свободной версии - с натяжкой. В составе накопительной статистики PgSQL есть представление pg_stat_activity, которое представляет текущий срез состояния, аналогично подсистеме Oracle AWR - ASH. Однако сама информация по сравнению с Oracle ASH очень ограниченна, и предоставляется только на момент "сейчас". Но, к нашему удовлетворению, существует ряд расширений, как идущих с составе поставки СУБД, так и устанавливаемых их репозитариев сообщества, которые позволяют довести статистику до довольно целостной картины. Ниже распишу именно такие уже доступные расширения и выводы по предоставляемыем ими возможностям, а далее, возможно поговорим и об их недостатках и путях решения. Здесь же отметить, что такой базовой информации хватит для начальной организации периодического сохранения статусов, а в Oracle ASH сохраняется в периодичностью в целую секунду и вполне работает, чтобы составить аналогичную Oracle TOP Activity картину распределения нагрузки по запросам и сессиям с накопительными гистограммами. Путём объединения таких выборок с данными расписанных ниже расширений и системной функции pg_blocking_pids, или, что не рекомендуется в документации, представления pg_locks, можно составить гораздо более полновесную строку ASH, включающую данные о блокирующих сессиях, задействованных объектах, sql верхнего уровня и статистике текукщего запроса, и т.д. Это будет меньше, чем строка ASH в Oracle, но уже вполне достаточно для части типовых практических задач ретроспективной аналитики. С использованием расширения pg_query_stat, можно было бы подсмотреть и точно корректный план, и даже его текущую фазу, что уже приблизит такую выборку к возможностям Oracle ASH вплоть до трассировки сессий. Жаль только, что работоспособный пакет СУБД, с которым может работать pg_query_stat, это коммерческая редакция СУБД от Постгрес ПРО

Аналог статистик библиотечного кэша Библиотечного кэша общего архитектурно нет, точнее запросы могут кэшироваться в локальных областях памяти сеансов. А накопительная статистика есть ... В общедоступном случае организуется путём установки трёх расширений - pg_stat_statements, pg_store_plans, pg_kcache. Первое расширение поставляется с СУБД в contrib пакете, и собирает основные данные и статистики по отработанным в СУБД запросам, накапливая их. Второе и третье расширение ставятся из репозитария сообщества postgresql.org, или компилируются из исходников. Pg_kcache собирает расширенные статистики операций ввода/вывода, и возможно даже избыточно, а третье - собирает планы исполнения для отработанных запросов. Насколько эти планы соответствуют реальным, предстоит изучать, такая проблема для ряда инструментов в Oracle есть, поэтому ждёшь и тут. Альтернативно компания Постгрес ПРО поставляет расширение pg_query_stats, которое позволяет подсмотреть реальные данные, а также несовместимое с pg_stat_statements своё расширение pgpro_stats, которое собирает также и планы, и заявлена трассировка сессий, но мы сейчас рассматривает только доступные для публичной версии

Аналог статистик событий ожидания Такая информация представлена в представлении pg_stat_activity, но только на текущий момент. Однако есть доступное для всех расширение, написанное, опять же, специалистами компании PgPRO, pg_wait_sampling, которое собирает данные о событиях ожидания, и агрегирует их в профиль нагрузки. Благодаря этом упредставлению можно получить как текущее состояние в разрезе по сессиям и запросам, так и его некоторую историю, и сводный профиль нагрузки, вероятно жеж накопительный. С учетом того, что разработчики озаботились легковесным сборщиком, сэмплирование по умолчанию проводится 100 раз в секунду, каждые 10 миллисекунд, тогда как записи ASH в Oracle фиксируются раз в секунду. Такой подход позволяет довольно представительно агрегировать как данные по событиям ожиданий суммарно по СУБД, так и в разрезах по сессиям и запросам

Аналог отчётов AWR Вот здесь с очень большой натяжкой. Автор расширения pg_profile сделал, казалось бы, нечто, позволяющее получать отчёт аналогичный Oracle AWR. В примерах отчёта действительно много информации, в том числе и по топовым запросам в разных разрезах. Однако здесь и проявляется, вероятно, полное непонимание ключевой информации отчёта AWR, которой является распределение нагрузки по классам событий ожиданий, и отдельных видов активностей - по процентам от общего DB time Oracle. Без этой информации отчёт pg_profile, при всей его красоте и проработанности, выливается в очень слабое подобие AWR и тех данных, на которые администратор обращает внимание и ориентируется в первую очередь. Также нет и других разделов - распределения событий ожиданий по длительности. Но здесь их просто неоткуда взять - ведь система сбора статистики Oracle в целом более детальнее и многозадачнее, а система Postgree SQL может показать вам количество фиксаций события ожидания, что для ряда задач уже немало, но не показывает их длительности. Само расширение написано целиком на процедурном языке Postgree SQL, и проводить аудит 1 мегабайта чужого кода никому не улыбается. Кстати в поставку Postgres PRO это расширение не включено, и ставить его на СУБД по мне стоило бы поостеречься. Хотя работа проделана большая, и стоит присмотреться

Хинты представлены расширением pg_hint_plan, которое удалось собрать из исходников для версии 15 под Scientific Linux 7.x. Расширение написано японцем, но в хранилище исходников GITHUB представлено в принадлежащем PostgresPRO разделе по ссылке. Установилось оно успешно, но, кроме разделяемой библиотеки, включает, как и pg_wait_sampling, некий байткод llvm. Расширение требует активного тестирования разработчиками. И нужно понимать, что этот модуль опубликован в публичном виде три года назад, и с тех пор не менялся, а вот сами СУБД ушли сильно вперёд. Однако на сайте сообщества это расширение, хоть и не представлено для старых версий, но представлено для 16 версии, устанавливаемой на 9 версию Linux, т.е. оно живое и его кто-то собирает

Фиксация планов, заявленная как реализация аналога Oracle Outlines, реализована с расширении sr_plan, также размещённого на GITHUB в разделе Постгрес ПРО по ссылке. Интересно, что на GITHUB опубликована версия 2х летней давности, которая может и не собираться на новых версиях СУБД. У меня эта версия и не собралась, сказав, что для ряда функций слишком мало аргументов, есть неверные указатели и т.п. В то же время Интернет подсказывает, что в новой 16 версии СУБД от Постгрес ПРО sr_plan переработан дальше. Но на github висит двухлетняя версия, которая не собирается для взятой с репозитария сообщества версии 15 для ОС RHEL 7.х, и в самом репозитарии сообщества этого расширения нет. Может оно соберётся под другую комбинацию версий СУБД и операционки ...

Адаптивный оптимизатор Это ещё один подход к выбора оптимальныз запросов, когда оптимизатор подглядывает в данные и выбирает оптимальный план для ваших аргументов запроса. В Oracle такой функционал появился, если не ошибаюсь, с 12 версии. Тут он тоже есть, и тоже о компании Постгрес ПРО

Трассировки и профилирование Посмотрю и сюда, хотя это больше к разработчикам, но в целом уже понятно, что полновесная работа и функционал, сопоставимый используемым активно в СУБД Oracle, есть только в коммерческой реализации СУБД Postgree SQL

различные аналоги DBMS_ пакетов Отдельные пакеты точно присутствуют и с репозитарии сообщества, и в поставке коммерческой версии СУБД от Постгрес ПРО. Эта задача должна решаться совместно с потребителями таких пакетов - разработчиками и оставлена до возникновения реальных потребностей. Например, расширение DUMP_STAT позволяет переносить статистику, AUTO_EXPLAIN протоколирует медленные запросы, DDLX позволяет соддавать для объектов скрипты создания, удаления, генерации дерева. PGCRYPTO реализует криптографические функции, LO работает с типами LOВ, хотя вместо них на курсах усиленно рекомендовали использовать поля типом ABYTE, AUTO_EXPLAIN собирает статистику медленных запросов по фильтру длительности, PG_CRON является планировщиком внутри СУБД

Потолки и ограничения Описанные выше расширения, как и другие, вкупе с накопительной статистикой СУБД имеет свои потолки и ограничения, описанные в том числе в документации. Самое первое ограничение - отсутствие уже готовой сборки расширения в известных репозитариях. Здесь нужно быть готовым компилировать расширения из исходников, которые лежат на github (для PgPRO) или другом хранилище исходников. Это может вылиться в целый квест, как получилось у меня при установке 15 версии СУБД на Scientific Linux 7x. Для того, чтобы поставить пакет разработки postgresql-15.devel, требовались утилиты llvm, которые отсутствовали в штатных репозитариях операционной системы. И если для чистого RHEL и его клона CentOS описание удалось найти относительно быстро, то для такого же клона RHEL - Scientific Linux - пришлось подсовывать репозиторий CentOS, временно создав файл репо в системе

Отдельные расширения не собираются только ка дополнения, а требуют патчевать исходные коды СУБД и пересобирать бинарники. Это не всегда допустимо. Примером является как раз pg_query_state, в файле описания которого cказано: "... The pg_query_state module provides facility to know the current state of query execution on working backend. To enable this extension you have to patch the stable version of PostgreSQL, recompile it and deploy new binaries. All patch files are located in patches/ directory and tagged with suffix of PostgreSQL version number ..."

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

Выводы С учетом изложенного выше никакой непреодолимой пропасти в части статистик между СУБД Oracle и СУБД POstgreeSQL не существует. Да, в Postgres SQL нужно искать продукты, обеспечивающие периодическое сохранение статистик и их обработку, которых - безоплатных именно - может и не быть. Но самое важное - источник данных - существует даже в общедоступной версии и доступен для использования. В Oracle механизмы сохранения и аналитических AWR отчётов уже реализованы, что позволяет инженеру по поддержке использовать эти очень востребованные механизмы сразу. А вот в части не менее востребованной - тюнинга запросов, фиксации планов, работы адаптивного оптимизатора и трассировок - расширения тоже есть, но для коммерческой версии СУБД от Постгрес ПРО

Значит ли это, что для общедоступной, называемой ещй ванильной, версии СУБД Postgree SQL в части анализа и управляемости всё плохо и можно только использовать СУБД с минимальными возможностями анализа и настройки ? Доступные в безоплатной версии расширения и встроенная система статистики всё же позволяют надеяться на возможности некоторого анализа функционирования СУБД. Теоретически можно оценить загрузку системы по сессиям и запросам в ретроспективе, выделив наиболее часто встречающиеся, проанализировать статистики запросов в части времени парсинга и выполнения, количеству операций логических и физических чтений и их времени, обращений ко временным сегментам. Кроме этого, в накопитеольной статистике есть ряд представлений, отражающих активность работы с таблицами и индексами, и активность сервисных операций и подсистем СУБД. Что дальше можно сделать с полученными выводами - можно попробовать переписать запросы. Возможно даже как то отработает собравшийся модуль, обеспечивающий хинты. Кстати в репозитарии сообщества для 9 версии ОС RHEL и 16 ванильной версии СУБД этот модуль появился, а в более ранних 7.9_OS + 15_RDBMS его нет. Или в сессиях внутри процедуры разработчику придётся отключать те или иные опции оптимизатора перед отдельными запросами, чтобы выбирались другие. В любом случае это уже возможности по изменению

Что сделать пока не представляется реальным без платной версии СУБД и ее платных расширений ? Нельзя закрепить план запроса (расширение sr_plan), получить расширенные данные для ретроспективной аналитики (расширение pg_query_state) по фазам выполнения запроса, а также запустить трассировку по сессии, или завести адаптивный оптимизатор с обратной связью с запросами и учётом значений аргументов запросов. Также возможно, расширенные модули статистики от ПостгресПРО обеспечивают сбор статистики не только с большей детализацией и меньшей нагрузкой на систему, но и учитывают какие то неочевидные для первых касаний нюансы. Однако даже ванильная версия предоставляе впечатляющий набот возможностей, которые, однако, ещё нужно научиться использовать, если найдутся свободно распространяемые инструменты или же самостоятельно делая аналитику через запросы

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

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

-- мои общие выводы по исследованию доступных статистических расширений и накопительной статистики
-- pg_stat_activity - упрощённый аналог ASH, есть процесс, запрос, класс и событие ожидания 
-- pg_stat_statements - аналог статистики библиотечного кэша, более полный вместе с pg_store_plans
-- pg_locks - данные по всем блокировкам - лёгким, тяжёлым
-- pg_store_plans - сохраняет планы, но для одного запроса пока вижу только 1 план
-- pg_wait_sampling - аналог системы сбора событий ожидания в моменте (current), списки выборок (history), профили (накопительная)
--                    (можно сделать системные, сессионные и запросные) и профилей для них. Это отдано сообществу, но делали ПостгресПРО
-- pg_stat_kcache
-- ddlx - аналог DBMS_DDL. позволяет соддавать для объектов скрипты создания, удаления, генерации дерева

select * from pg_stat_activity ; - упрощённый аналог ASH
select * from pg_stat_statements(false) ;
select * from pg_locks ;

-- объединение трёх основных таблиц не даёт полного аналога ASH
-- во-первых нет планов выполнения
-- во-вторых одна сессия может держать много блокировок - нет однострочной структуры
-- думаю, проще сохранять каждую 1-5 секунду все три таблицы, а объединять потом под задачу
select sa.pid, pg_blocking_pids(sa.pid), sa.*, lck.*, pss.*
       from pg_stat_activity sa 
            left outer join pg_locks lck ON sa.pid = lck.pid
                 left outer join pg_stat_statements(false) pss on sa.query_id = pss.queryid 
       order by sa.pid ;

-- вот вариант объединения только активности и запроса - это простой однострочный аналог ASH без планов и разного иного
select sa.pid, pg_blocking_pids(sa.pid), sa.*, pss.*
       from pg_stat_activity sa 
            left outer join pg_stat_statements(false) pss on sa.query_id = pss.queryid
       order by sa.pid ;


-- доустановлены из репозитария pg_store_plans_15, pg_wait_sampling_15, pg_stat_kcache_15 - для ванильной уже неплохо, но нет трассировки
create extension pg_store_plans ;
select * from  pg_store_plans ;

-- хотя в документации написано, что queruid считаются по разному в pg_stat_statements и pg_store_plans, и нужно объединять по queryid_stat_statements
-- практика показала, что этого поля во втором представлении нет, а объединяются прекрасно и по просто queryid
-- !!! но PostgreePRO поставляют вместо этого пакет pg_query_state, который вытаскивает реальный план выполнения,
-- !!! а также замещающий stat_statements свой пакет pgpro_stats, который кроме статистики запросов умеет ещё планы, и трассировку
select psp.queryid, psp.queryid, * from  pg_store_plans psp, pg_stat_statements pss where psp.queryid = psp.queryid ;

-- запрос с объединением статистики запросов и планов
select psp.queryid, psp.queryid, * from  pg_stat_statements(false) pss LEFT OUTER JOIN pg_store_plans psp ON psp.queryid = pss.queryid ;

-- вариант увязки с таблицей текущей активности
select sa.pid, pg_blocking_pids(sa.pid), sa.*, pss.*
       from pg_stat_activity sa
            left outer join pg_stat_statements(false) pss on sa.query_id = pss.queryid
                 left outer join pg_store_plans psp ON sa.query_id = psp.queryid
       order by sa.pid ;

-- а вот проверка - на каждый queryid действительно только один план, что вызывает вопросы и требует исследований
select queryid, planid, count(*) from pg_store_plans group by queryid, planid order by 3 desc ;
select queryid, planid, count(*) from pg_store_plans group by queryid, planid HAVING count(*) > 1 ;
--  сервисные запросы
select * from pg_class where relname = 'pg_store_plans';

-- это расширение показывает детальные статистики ОС для запроса, отдельно может считать и для планов
create extension pg_stat_kcache ;
select * from pg_stat_kcache() ;
select * from pg_stat_kcache_detail ;

-- это расширение как бы делает часть AWR/StatsPack
create extension pg_wait_sampling ;
select * from pg_wait_sampling_current ;
-- текущая активность с событиями ожиданий
-- избыточно, т.к. данные о текущих событиях ожидания и так лежат в pg_stat_activity, и совпадают
select sa.pid, pg_blocking_pids(sa.pid), sa.*, pwsc.*
       from pg_stat_activity sa 
            left outer join pg_wait_sampling_current pwsc on sa.pid = pwsc.pid
       order by sa.pid ;
 
-- текущая активность с профилем ожиданий по процессам, без разбивки по запросам
select sa.pid, pwsp.*
       from pg_stat_activity sa
            left outer join
            (select pid, event_type, event, sum(count) cnt
                    from pg_wait_sampling_profile
                    group by pid, event_type, event) pwsp on sa.pid = pwsp.pid
       order by sa.pid ;

-- текущая активность с профилем ожиданий по запросам, без разбивки по процессам
-- похоже такой формат не работает, т.к. данные попадают с запозданием, а не realtime
-- иногда что то мелькает. Но нужно исследовать
-- PostgresPRO поставляет расширение query_state, подсматривающее текущую активность в запросах
select sa.query_id, pwsp.*
       from pg_stat_activity sa
            left outer join
            (select queryid, event_type, event, sum(count) cnt
                    from pg_wait_sampling_profile
                    group by queryid, event_type, event) pwsp on sa.query_id = pwsp.queryid
       order by sa.query_id ;

select * from pg_wait_sampling_history order by pid,ts ;
select * from pg_wait_sampling_profile order by pid ;

-- вот так я собираю статистику
CREATE TABLE IF NOT EXISTS public.besst_stat_ash_history(pid integer, ts timestamp with time zone, event_type text, event text, queryid bigint) ;
CREATE OR REPLACE PROCEDURE public.besst_stat_fill_ash_table()
LANGUAGE 'plpgsql'
AS $BODY$
begin
MERGE INTO public.besst_stat_ash_history bsah
      USING public.pg_wait_sampling_history pwsh
      ON bsah.pid = pwsh.pid AND bsah.ts = pwsh.ts
      WHEN NOT MATCHED THEN
           INSERT (pid, ts, event_type, event, queryid)
                  VALUES (pwsh.pid, pwsh.ts, pwsh.event_type, pwsh.event, pwsh.queryid) ;
end ;
$BODY$;



LOAD 'auto_explain' ;
SET auto_explain.log_min_duration = -1;

Белонин С.С. (С), 29 апреля 2024 года
(история последующих модификаций не фиксируются)