В Платформе есть снепшоты и блокировок и активных сессий с историей. Причем информация о взаимоблокировках "дообогащается" информацией, которой нет в логах и позволяет быстро понять какой процесс блокировал. Сделать подобный велосипед с парсингом логов, хождение в БД, гистограммами и т.д. уже не выглядит простой задачей. Добавим сюда возможность прям из интерфейса подключиться к БД и глянуть схему, написать свой SQL, чтобы быстро посмотреть какую-то информацию или сконфигурировать группу инстансов одним конфигом через групповые параметры или сделать анонимизированный дамп или через профилировщик найти, что не хватает индекса, и вот уже мы получаем "швейцарский нож" для DBA. Не хватает чего-то? Есть планировщик задач, где можно запустить любой SQL или bash/python скрипт и т д. И все это бесплатно, если куплена СУБД. Можно ли собрать такое на open source или бесплатных инструментах типа pgAdmin? Не уверен. Будет набор разнородных, несвязанных продуктов, скрипты и т д. А завтра сменил работу и все это хозяйство досталось новому DBA, который выбросит все и построит свой велосипед, потому что "потому" :)
Так что, если б у меня в свое время был такой кот, может я бы и не женился :)
Это очень субъективно, на мой взгляд, оценивать установку СУБД и GUI. Платформа гораздо более зрелый продукт и на рынке(в тот числе международном) с 2020 года, тогда как PPEM с конца 2023 года. Если интересно сравнение, то был целый доклад на PgConf об этом. Не знаю насколько он был объективен, не присутствовал.
Старый добрый pipelinedb умер в 2019 году. Справедливости ради, стоит отметить, что репа родилась 25 марта 2025 года, перед pgBootCamp 2025 в Екатеринбурге, о чем и был доклад.
Это opensource расширение, доступное на github по лицензии Apache 2.0 и за него платить ничего не нужно, чтобы начать использовать. Если нужна поддержка - тогда welcome к вендору.
На вскидку, например, иметь возможность управлять SLRU буфферами, при большом количестве соединений (сотни, тысячи) и транзакций(десятки-сотни тысяч). Эти патчи в ядро, есть в некоторых СУБД из вышеупомянутой статьи.
https://github.com/IvorySQL/IvorySQL
В Платформе есть снепшоты и блокировок и активных сессий с историей. Причем информация о взаимоблокировках "дообогащается" информацией, которой нет в логах и позволяет быстро понять какой процесс блокировал. Сделать подобный велосипед с парсингом логов, хождение в БД, гистограммами и т.д. уже не выглядит простой задачей. Добавим сюда возможность прям из интерфейса подключиться к БД и глянуть схему, написать свой SQL, чтобы быстро посмотреть какую-то информацию или сконфигурировать группу инстансов одним конфигом через групповые параметры или сделать анонимизированный дамп или через профилировщик найти, что не хватает индекса, и вот уже мы получаем "швейцарский нож" для DBA. Не хватает чего-то? Есть планировщик задач, где можно запустить любой SQL или bash/python скрипт и т д. И все это бесплатно, если куплена СУБД. Можно ли собрать такое на open source или бесплатных инструментах типа pgAdmin? Не уверен. Будет набор разнородных, несвязанных продуктов, скрипты и т д. А завтра сменил работу и все это хозяйство досталось новому DBA, который выбросит все и построит свой велосипед, потому что "потому" :)
Так что, если б у меня в свое время был такой кот, может я бы и не женился :)
Это очень субъективно, на мой взгляд, оценивать установку СУБД и GUI. Платформа гораздо более зрелый продукт и на рынке(в тот числе международном) с 2020 года, тогда как PPEM с конца 2023 года. Если интересно сравнение, то был целый доклад на PgConf об этом. Не знаю насколько он был объективен, не присутствовал.
Старый добрый pipelinedb умер в 2019 году. Справедливости ради, стоит отметить, что репа родилась 25 марта 2025 года, перед pgBootCamp 2025 в Екатеринбурге, о чем и был доклад.
Это opensource расширение, доступное на github по лицензии Apache 2.0 и за него платить ничего не нужно, чтобы начать использовать. Если нужна поддержка - тогда welcome к вендору.
Реализовано, как расширение pg_uuidv7, начиная с версии
16.8.x+и 17.5.x+Тест TPC-B(pgbench);
БД - 3TB;
Профиль нагрузки - RW, с классическим распределением нагрузки - 80% read, 20% write;
Количество одновременных пользователей - 100;
Пиковые значения TPS - 66k, среднее значение ~60k TPS
На вскидку, например, иметь возможность управлять SLRU буфферами, при большом количестве соединений (сотни, тысячи) и транзакций(десятки-сотни тысяч). Эти патчи в ядро, есть в некоторых СУБД из вышеупомянутой статьи.