Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 9
>> Новый инструмент с открытым исходным кодом...
>> https://gitflic.ru/project/kznalp/pg_expecto
А в репе архивы... 21 век, а месье знает толк... как выкладывать исходники на git
Уж простите, но не удержался.
Какой смысл их выкладывать на git в архивах? как я могу понять что Вы там между версией 2 и 3 поменяли? Выкладывайте тогда уж на yandex disk
Вы первый на Хабре, кто зашел посмотреть репозиторий .
Ок. Принято , возможно, сегодня выложу в папках.
Просто zip архивами проще инсталлировать .
Спасибо за обратную связь . Неужели кому то кроме меня, тема статистического анализа производительности СУБД стала интересна ?
как я могу понять что Вы там между версией 2 и 3 поменяли?
Есть файл HISTORY.md
>Неужели кому то кроме меня, тема статистического анализа
Она интересна, но у Вас статья/и написаны суховато, голые формуры и 2 скриншота. Формулы я и в книжке могу почитать, причем с детализацией.
Интересно знать детали метода и прочие технические аспекты.
>Просто zip архивами проще инсталлировать .
Проще это когда есть готовые deb/rpm пакеты под нужную ОС, все остальное - компромис и какое-то количество ручной работы по установке.
Посмотрите для примера как оформлены модули для пг, например pg_wait_sampling (да там нет пакетов, но zip архив формируется в релизе через пайплайн, а не лежит в репе, есть инструкция по установке, сборке и использованию в README, ну и конечно видно все исходники и можно посмотреть что и когда там менялось)
>Есть файл HISTORY.md
Он не нужен если у Вас будут формироваться релизы с архивами, там обычно и пишут историю изменения в версии (см опять же pg_wait_sampling). Ну и в HISTORY.md не пишут, обычно файл называется CHANGELOG.md.
Интересно знать детали метода и прочие технические аспекты.
Большая статья по теме по основам и теоретической части с практическими примерами
https://dzen.ru/a/aGYjGIt_KDOjmf35
Завтра будет год как создан Дзен-канал
Материалов много, за год и теория и технические аспекты. Только судя по отсутствию вопросов в комментариях - опять таки не интересно никому.
После подготовки и начала тестирования расширения pg_expecto будут и на Хабре статьи и новости, но в третью очередь после Дзена и Пикабу. Потому, что читатели Хабра слили карму , теперь 1 статья в неделю. Пока еще комментировать могу раз в 5 минут, но возможно скоро и эта возможность будет ограничена до часу(т.е. без комментариев на самом деле, через час я и забуду о чем и про что была мысль)
но zip архив формируется в релизе через пайплайн
вряд ли я найду время и главное желание настолько углубляться в DevOps.
Посмотрите для примера как оформлены модули для пг, например pg_wait_sampling
Спасибо за информацию , принято . Будет время , буду полировать. Так, то я не DevOps , для DBA использования Git и CI/CD задача очень редкая.
Ну и в HISTORY.md не пишут, обычно файл называется CHANGELOG.md.
Странно, я как раз чаще встречал history. Но в принципе , пусть будет changelog . Может быть сегодня поменяю. Мне в общем то без разницы.
FYI
Создан репозиторий на GitHub
Пайплайны пока не настроены, в процессе.
Чем же gitflic не угодил? Кстате на github в любом проекте можно включить Wiki и писать всю документацию там. Это и удобней и не нужно держать в репе папку doc. Wiki по сути тот же git у которого можно смотреть историю изменений.
Вообще если это расширение пг, то кроме него ничего не должно быть в репе. Для тестирования расширения и если Вы пишите статьи делают отдельные репы с набором скриптов и скриншотов и ссылками на оригинальную статью. Это просто бесплатный совет.
Развивайте расширение, в README.md к нему пишите ссылки на статьи и тп. Не сгребайте все в одну кучу - это неудобно.
Ну и ИМХО источник правды (репо) должен быть один, а не 100500, я это к тому что если переехали на github, то на gitflic сделайте пометку или удалите его или сделайте gitflic зеркалом github (если есть такой функционал у gitflic)
Чем же gitflic не угодил?
Я так и не разобрался как делать папки в проекте
Кстате на github в любом проекте можно включить Wiki и писать всю документацию там. Это и удобней и не нужно держать в репе папку doc.
Не все сразу
Вообще если это расширение пг, то кроме него ничего не должно быть в репе.
IMHO расширение само по себе не имеет никакого практического смысла. Ну например - вот поставил расширение pg_stat_statements и что , ну запросы, цифры какие то какой в них практический смысл ? Искать нужно фильтровать мегатонны статей из которых половина не имеет практического смыслы а част давно устарела.
Моя мысль была такая - вот репозиторий, кому интересно - берет zip-ы , запускает инсталлятор по инструкции, запускает нагрузочное тестирование , отчеты и смотрит , что получилось, если дальше интересно - ну ставьте на продуктив и интегрируйте с мониторингом. Все в одном флаконе.
Контакты есть, если что непонятно - можно спросить. Пока судя по отсутствию комментариев и вопросов - никому не интересно, никто не ставил, не запускал, не проверял, не исследовал и не пытался проверить результаты экспериментов.
Ну нет так нет.
Вы первый из более 11000 просмотревших, кому стали интересны исходные коды.
Развивайте расширение, в README.md к нему пишите ссылки на статьи
Спасибо за обратную связь. Сейчас перенесу ссылки в readme из howto
Не сгребайте все в одну кучу - это неудобно.
Посмотрим, что получится дальше. Это мой первый проект в open source. Спасибо за наводки.
если это расширение пг, то кроме него ничего не должно быть в репе.
FYI отказался от идеи использовать расширение, в результате очень сильно все упростилось, особенно инсталляция.
Просто создается БД репозиторий для сервисных таблиц и функций.
Еще раз, спасибо за начальный комментарий. Плюсов поставить не могу , карма не позволяет. Ну чисто виртуально.
Тема анализа производительности и алармов очень интересна. Но статья как-будто написана chatgpt с плохим промптом - сухо, дергано, и не понятна ее цель, что именно вы хотели донести.
У меня не сложилось понимания как мне взять и попробовать, очень бы хотелось увидеть пошаговый рецепт внедрения и получения первых результатов. И уже после можно погружаться глубже - в то как оно устроено и в теорию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование pg_expecto для проактивного мониторинга производительности СУБД PostgreSQL