У действующего специалиста всегда есть материал: его собственные разработки.
Да. Именно так .
И это всегда интересно узнать о том, кто и как решает практические задачи.
Да . Именно так.
Но у такого специалиста может попросту не быть времени.
В самую точку. Основная претензия от коллег - у тебя ничего не понятно, мы хотим что бы ты потратил кучу своего личного времени , все разжевал и нам преподнес на блюдечке с голубой каемочкой. Мы не хотим тратить свое время на то, что бы думать и анализировать , мы хотим потреблять контент. Мы хотим что бы был все понятно на уровне школьника как в ТикТоке.
Ребята а мне кто эту работу оплатит и зачем мне это надо ? Кому интересно - может спросить, контакты и комментарии есть, кто ничего не понял ну на нет и суда нет.
Я не могу тратить кучу своего личного времени жизни на подготовку статей по теме, которая в общем то практически никому особо и не интересна, что бы было понятно вообще всем . Записал результаты экспериментов для будущих работ и индексации страницы поисковиками и нейросетями и иду дальше. Работы на долго хватит. Тема - реально напаханная целина. Может кому интересно будет, а может и нет. Мне не особо важно, главное - мне интересно.
И если каждый напишет что-то из своего опыта, то Хабр наполнится чем-то полезным.
И в ответ получишь кучу минусов с причинами "Ничего не понял", "Личная неприязнь" , "В статье нет новой информации", "Низкий технический уровень".
Конечно же , теперь это не проблема и даже для SEO Хабр давно уже не единственный ресурс. Есть другие ресурсы , с другой публикой.
Но получив минусы по таким причинам, во-первых не очень то и хочется делится с аудиторией следующими статьями, во-вторых автоматически сливается карма и Хабр оказывается в хвосте очереди при публикации новых материалов.
Так, что аудитория Хабра сливая карму авторам, сама снижает просмотры Хабру.
Но видать администрацию эта политика вполне устраивает. Так, что особо проблем нет.
Кстате на github в любом проекте можно включить Wiki и писать всю документацию там. Это и удобней и не нужно держать в репе папку doc.
Не все сразу
Вообще если это расширение пг, то кроме него ничего не должно быть в репе.
IMHO расширение само по себе не имеет никакого практического смысла. Ну например - вот поставил расширение pg_stat_statements и что , ну запросы, цифры какие то какой в них практический смысл ? Искать нужно фильтровать мегатонны статей из которых половина не имеет практического смыслы а част давно устарела.
Моя мысль была такая - вот репозиторий, кому интересно - берет zip-ы , запускает инсталлятор по инструкции, запускает нагрузочное тестирование , отчеты и смотрит , что получилось, если дальше интересно - ну ставьте на продуктив и интегрируйте с мониторингом. Все в одном флаконе.
Контакты есть, если что непонятно - можно спросить. Пока судя по отсутствию комментариев и вопросов - никому не интересно, никто не ставил, не запускал, не проверял, не исследовал и не пытался проверить результаты экспериментов.
Ну нет так нет.
Вы первый из более 11000 просмотревших, кому стали интересны исходные коды.
Развивайте расширение, в README.md к нему пишите ссылки на статьи
Спасибо за обратную связь. Сейчас перенесу ссылки в readme из howto
Не сгребайте все в одну кучу - это неудобно.
Посмотрим, что получится дальше. Это мой первый проект в open source. Спасибо за наводки.
Материалов много, за год и теория и технические аспекты. Только судя по отсутствию вопросов в комментариях - опять таки не интересно никому.
После подготовки и начала тестирования расширения pg_expecto будут и на Хабре статьи и новости, но в третью очередь после Дзена и Пикабу. Потому, что читатели Хабра слили карму , теперь 1 статья в неделю. Пока еще комментировать могу раз в 5 минут, но возможно скоро и эта возможность будет ограничена до часу(т.е. без комментариев на самом деле, через час я и забуду о чем и про что была мысль)
но zip архив формируется в релизе через пайплайн
вряд ли я найду время и главное желание настолько углубляться в DevOps.
Посмотрите для примера как оформлены модули для пг, например pg_wait_sampling
Спасибо за информацию , принято . Будет время , буду полировать. Так, то я не DevOps , для DBA использования Git и CI/CD задача очень редкая.
С меня, недели через 3-4, статья об использовании генератора в качестве инструмента нагрузки для тестового стенда нагрузочного тестирования и анализа производительности СУБД PostgreSQL. Тема в работе.
Только для имитации продуктивной нагрузки надо будет добавить постоянную нагрузку на чтение - аналог запросов на просмотр расписаний. Конечно же тоже по распределению Пуассона.
Мне тоже , за ссылку на репозиторий и статьи о свободно распространяемом в исходниках расширении PostgreSQL ;-)
ну , а причины минусов - "Личная неприязнь" и "Ничего не понял" это классика Хабра ;-)
В результате, мог бы поделится много всяким интересным. Но, по желанию публики теперь только одна статья в неделю.
P.S. Впрочем минусы и слив кармы на Хабре вообще давно уже не проблема. Кому интересно - найдут материал на других ресурсах, а количество минусов на индексацию страницы никак не влияет.
В том то и дело. pgbench в качестве бенчмарка откровенно говоря не очень. Только для начального уровня что бы протестировать инструментарий и создавать тестовую нагрузку.
Можно ли смоделировать хаос пуассоновских потоков бронирований и конечный автомат состояний рейса (от «по расписанию» до «приземлился») целиком внутри PostgreSQL?
Спасибо ! У меня все руки не доходили до пуассоновского распределения.
Вот на этой демо базе и будет развиваться методика статистического анализа производительности СУБД .
Вместо старых статичных таблиц мы построили генератор, имитирующий жизнь глобальной авиакомпании.
Если я правильно понимаю идею - готовый стендовый тест нагрузочного тестирования ?
Для получения необходимых для расчетов данных используются представления расширения pgpro_stats:
1)Представление pgpro_stats_statements
Статистика, собираемая модулем, выдаётся через представление с именем pgpro_stats_statements. Это представление содержит отдельные строки для каждой комбинации идентификатора базы данных, идентификатора пользователя и идентификатора запроса.[1]
2)Представление pgpro_stats_totals
Агрегированная статистика, собранная модулем, выдаётся через представление pgpro_stats_totals. Это представление содержит отдельные строки для каждого отдельного объекта БД[2]
Используемые столбцы:
· calls Счётчик выполнений данного оператора
· rows Общее число строк, полученных или затронутых оператором
Данные собираются по СУБД в целом (pgpro_stats_totals) и по каждому SQL (pgpro_stats_statements) в отдельности.
Хотя , в расширении pg_expecto не используется pgpro_stats( в отличии от комплекса pg_hazel), терминология принципиально не отличается.
Точка наблюдения
Периодичность сбора данных для статистического анализа (медианное сглаживание и агрегация) = 1 минута. Таким образом - Точка наблюдения это номер минуты в ходе теста.
А как по вашему можно объяснить минусы под статьями без комментариев?
Или причины минусов "Личная неприязнь" , "Ничего не понял" , "Не согласен" - чем кроме хейтерства или троллинга можно объяснить ?
Конечно можно, только по правилам 1 раз , и при этом те кто минусовал , смогут опять заминусить.
И какой смысл ?
FYI отказался от идеи использовать расширение, в результате очень сильно все упростилось, особенно инсталляция.
Просто создается БД репозиторий для сервисных таблиц и функций.
Еще раз, спасибо за начальный комментарий. Плюсов поставить не могу , карма не позволяет. Ну чисто виртуально.
IMHO
Да. Именно так .
Да . Именно так.
В самую точку. Основная претензия от коллег - у тебя ничего не понятно, мы хотим что бы ты потратил кучу своего личного времени , все разжевал и нам преподнес на блюдечке с голубой каемочкой. Мы не хотим тратить свое время на то, что бы думать и анализировать , мы хотим потреблять контент. Мы хотим что бы был все понятно на уровне школьника как в ТикТоке.
Ребята а мне кто эту работу оплатит и зачем мне это надо ? Кому интересно - может спросить, контакты и комментарии есть, кто ничего не понял ну на нет и суда нет.
Я не могу тратить кучу своего личного времени жизни на подготовку статей по теме, которая в общем то практически никому особо и не интересна, что бы было понятно вообще всем . Записал результаты экспериментов для будущих работ и индексации страницы поисковиками и нейросетями и иду дальше. Работы на долго хватит. Тема - реально напаханная целина. Может кому интересно будет, а может и нет. Мне не особо важно, главное - мне интересно.
И в ответ получишь кучу минусов с причинами "Ничего не понял", "Личная неприязнь" , "В статье нет новой информации", "Низкий технический уровень".
Конечно же , теперь это не проблема и даже для SEO Хабр давно уже не единственный ресурс. Есть другие ресурсы , с другой публикой.
Но получив минусы по таким причинам, во-первых не очень то и хочется делится с аудиторией следующими статьями, во-вторых автоматически сливается карма и Хабр оказывается в хвосте очереди при публикации новых материалов.
Так, что аудитория Хабра сливая карму авторам, сама снижает просмотры Хабру.
Но видать администрацию эта политика вполне устраивает. Так, что особо проблем нет.
Я так и не разобрался как делать папки в проекте
Не все сразу
IMHO расширение само по себе не имеет никакого практического смысла. Ну например - вот поставил расширение pg_stat_statements и что , ну запросы, цифры какие то какой в них практический смысл ? Искать нужно фильтровать мегатонны статей из которых половина не имеет практического смыслы а част давно устарела.
Моя мысль была такая - вот репозиторий, кому интересно - берет zip-ы , запускает инсталлятор по инструкции, запускает нагрузочное тестирование , отчеты и смотрит , что получилось, если дальше интересно - ну ставьте на продуктив и интегрируйте с мониторингом. Все в одном флаконе.
Контакты есть, если что непонятно - можно спросить. Пока судя по отсутствию комментариев и вопросов - никому не интересно, никто не ставил, не запускал, не проверял, не исследовал и не пытался проверить результаты экспериментов.
Ну нет так нет.
Вы первый из более 11000 просмотревших, кому стали интересны исходные коды.
Спасибо за обратную связь. Сейчас перенесу ссылки в readme из howto
Посмотрим, что получится дальше. Это мой первый проект в open source. Спасибо за наводки.
FYI
Создан репозиторий на GitHub
pg-expecto/pg_expecto: Расширение pg_expecto для статистического анализа производительности СУБД PostgreSQL
Пайплайны пока не настроены, в процессе.
Большая статья по теме по основам и теоретической части с практическими примерами
https://dzen.ru/a/aGYjGIt_KDOjmf35
Завтра будет год как создан Дзен-канал
https://dzen.ru/kznalp
Материалов много, за год и теория и технические аспекты. Только судя по отсутствию вопросов в комментариях - опять таки не интересно никому.
После подготовки и начала тестирования расширения pg_expecto будут и на Хабре статьи и новости, но в третью очередь после Дзена и Пикабу. Потому, что читатели Хабра слили карму , теперь 1 статья в неделю. Пока еще комментировать могу раз в 5 минут, но возможно скоро и эта возможность будет ограничена до часу(т.е. без комментариев на самом деле, через час я и забуду о чем и про что была мысль)
вряд ли я найду время и главное желание настолько углубляться в DevOps.
Спасибо за информацию , принято . Будет время , буду полировать. Так, то я не DevOps , для DBA использования Git и CI/CD задача очень редкая.
Странно, я как раз чаще встречал history. Но в принципе , пусть будет changelog . Может быть сегодня поменяю. Мне в общем то без разницы.
Вы первый на Хабре, кто зашел посмотреть репозиторий .
Ок. Принято , возможно, сегодня выложу в папках.
Просто zip архивами проще инсталлировать .
Спасибо за обратную связь . Неужели кому то кроме меня, тема статистического анализа производительности СУБД стала интересна ?
Есть файл HISTORY.md
Спасибо за информацию и уточнения по генератору.
С меня, недели через 3-4, статья об использовании генератора в качестве инструмента нагрузки для тестового стенда нагрузочного тестирования и анализа производительности СУБД PostgreSQL. Тема в работе.
Спасибо за информацию. Принято в работу.
Только для имитации продуктивной нагрузки надо будет добавить постоянную нагрузку на чтение - аналог запросов на просмотр расписаний. Конечно же тоже по распределению Пуассона.
Вопрос по генератору (GitHub - postgrespro/demodb: Demonstration Database )
Возможно ли использовать генератор как инструмент создания нагрузки на тестовую БД в ходе нагрузочного тестирования:
Где N - увеличивается для каждой итерации .
Например каждые 10 минут , по cron .
Также просьба уточнить
Разве генератор не записывает данные в базу demо сразу ?
Мне тоже , за ссылку на репозиторий и статьи о свободно распространяемом в исходниках расширении PostgreSQL ;-)
ну , а причины минусов - "Личная неприязнь" и "Ничего не понял" это классика Хабра ;-)
В результате, мог бы поделится много всяким интересным. Но, по желанию публики теперь только одна статья в неделю.
P.S. Впрочем минусы и слив кармы на Хабре вообще давно уже не проблема. Кому интересно - найдут материал на других ресурсах, а количество минусов на индексацию страницы никак не влияет.
В том то и дело. pgbench в качестве бенчмарка откровенно говоря не очень. Только для начального уровня что бы протестировать инструментарий и создавать тестовую нагрузку.
Ок. Тема в работе. Посмотрим, что получится.
Спасибо ! У меня все руки не доходили до пуассоновского распределения.
Вот на этой демо базе и будет развиваться методика статистического анализа производительности СУБД .
Если я правильно понимаю идею - готовый стендовый тест нагрузочного тестирования ?
То, что нужно !
Спасибо еще раз.
Операционная скорость
Источник: https://dzen.ru/a/aGYjGIt_KDOjmf35
Таким образом, для расчета операционной скорости используется терминология из описания представления pgpro_stats :
callsСчётчик выполнений данного оператораrowsОбщее число строк, полученных или затронутых операторомPostgres Pro Enterprise : Документация: 15: G.5. pgpro_stats : Компания Postgres Professional
Хотя , в расширении pg_expecto не используется pgpro_stats( в отличии от комплекса pg_hazel), терминология принципиально не отличается.
Точка наблюдения
Периодичность сбора данных для статистического анализа (медианное сглаживание и агрегация) = 1 минута. Таким образом - Точка наблюдения это номер минуты в ходе теста.
Спасибо за вебинар. Было интересно.
К следующему вебинару по теме "Instance Tuning" - вопросов будет сильно больше.