это просто реакция сообщества, на то что ты ведешь себя как спамер
Ну и замечательно - ты сохранишь время , что бы не читать новые публикации по теме оптимизации производительности СУБД PostgreSQL , тем более тебе лично сказать сообществу по теме и нечего, кроме бессмысленных комментариев.
Я - использую время освободившееся от подготовки новых публикаций на Хабре на новые эксперименты и публикации на других ресурсах.
Сообщество - продолжить читать ленту Хабра про ИИ , HRов , менеджеров , психологов и прочих очень актуальных на техническом ресурсе материалов , наверное сообществу это очень интересно. Why not.
Администрация Хабра - передает просмотры и прочтения со своего ресурса, другим.
был один профиль нагрузки . В этой статье эксперимент поставлен для двух разных профилей нагрузки.
почему взяли 15 минут, а не 20 минут.
В связи с политикой Хабра публикуются только выборочные , итоговые результаты экспериментов (1 публикация в неделю). На дзен-канале (ссылка в профиле) масса публикаций по другим значениям checkpoint_timeout. Я не буду приводить ссылку на подборку публикаций , во избежание дальнейшего непрерывного слива кармы по причине "Реклама", если интересно - ссылка на дзен в профиле. На репозиторий инструмента, кстати тоже, если интересно можно все эксперименты проводить и проверять самостоятельно.
В настоящее время эксперименты по checkpoint_timeout - завершены(ну по крайней мере приостановлены). Общая идея понятна, методика отработана, инструмент протестирован, поставленные цели экспериментов - достигнуты. Сейчас проводятся эксперименты по другой теме. Может быть также будет итоговая публикация. Если к тому времени карму не сольют до read-only ;-)
P.S. Ну и разумеется, если уж очень интересно обсуждение темы - лучше в личных сообщениях или в комментариях на дзене. Тут - цензура и отсутствие свободы слова. Впрочем это не бага , это фича Хабра.
1) Инструмент готовит текстовый файл содержащий результаты статистического анализа (корреляции, регрессии , максимальные минимальные значения и т.п. ) и временные ряды метрик производительности СУБД и инфраструктуры
2) текстовые файлы загружаются в нейросеть, главное не превысить ограничение бесплатной версии (128K токенов). Если данных много , придётся анализировать производительность СУБД и инфраструктуры - отдельно.
3) Дальше есть варианты - либо использовать промпты из библиотеки использованных промптов , либо еще проще использовать базовый промпт - "используя входные данные , подготовь промпты для сводного анализа производительности СУБД и инфраструктуры по результатам эксперимента ".
4) Дальше используя уже загруженные данные и промты - дело техники - готовим сводный отчет.
Доступ нейросети никуда давать не нужно, главное - подготовить достаточный набор данных для анализа.
Примеры обработки нейросетью результатов нагрузочного тестирования и инцидентов производительности СУБД, если интересно - на дзен канале(ссылка в профиле) .
Ну а если сильно интересно - пишите в личку. Отвечать на комментарии хоть как-то оперативно - нет возможности, согласно политике Хабра.
LLM сильнее всего там, где для человека слишком много взаимосвязей.
Соглашусь и подтверждаю практическую применимость данного тезиса.
У меня задача сильно проще - есть очень много таблиц и временных рядов , задача найти корреляции и взаимосвязи между данными . Нейросеть , даже в самом простом бесплатном варианте - отлично справляется , дает практически применимый результат и экономит очень много времени на анализ данных.
LLM нормальный и полезный инструмент , если использовать для задач для которых LLM предназначены.
P.S. Например , для прогнозирования нейросети очень плохо приспособлены.
Импорт больших текстовых файлов с временными рядами и возможность анализа данных, кластеризации и выявления корреляций .
И можно будет сравнить с результатами анализа, выполненного другой большой известной нейросетью . Наверное будет интересно . И главное - реальная практическая польза для анализа инцидентов производительности СУБД.
P.S. И пользуясь случаем - просьба сделать вывод результата без псевдографики , в простом текстовом виде. Для дальнейшего протоколирования и анализа в текстовых редакторах.
С академической точки зрения , корректно заявлять не о повышении производительности, а о снижении стоимости выполнения конкретного запроса в условиях единичного изолированного выполнения.
В общем то классика уже - стоимость выполнения отдельного запроса это не производительность СУБД в целом.
Снижение стоимости выполнения запроса не является необходимым и достаточным условием повышения производительности СУБД в целом.
Сценарий когда снижение стоимости запроса не приводит к повышению производительности СУБД в ходе нагрузочного тестирования, а даже наоборот - известны , описаны и опубликованы.
Но в целом , спасибо за информацию и очередную тему для экспериментов 👍🤝.
Предполагается, что вы должны сделать вывод, что на этом ресурсе нет людей, которым интересны ваши статьи, и публиковать их на другом ресурсе.
Немножко перепутана последовательность. Сначала публикации на других ресурсах, потом Хабр для разнообразия и, как было сказано SEO.
Если я буду искать инструменты для измерения производительности PostgreSQL, и Google мне покажет статью на Хабре с рейтингом -3 и с кармой автора -10, я просто ее закрою, и этот инструмент использовать не буду.
Ну и не используйте. Это вообще ни на что не влияет. Я как автор никак не узнаю , что кто то абсолютно неизвестный принципиально не хочет использовать статистический анализ производительности СУБД PostgreSQL на основании рейтинга Хабра 😁
Посмотрел ваш профиль - зачем вам результаты экспериментов и исследований производительности СУБД PostgreSQL? Не используйте , мои статьи не читайте , добавьте меня в черный список.
Нет, вы в корне не правы - автору глубоко плевать и на минусы и на причины тем более .
Результаты и планы экспериментов от реакции и плюсов минусов к публикациям на Хабре, вообще никак не зависят. Цифрам все равно, что про них думаю прохожие .
Ну под автором я про себя конечно, не знаю может быть на Хабре есть авторы реально переживающие за реакцию читателей. Может , кто и ответит .
Возникает закономерный вопрос - а зачем ты тогда на Хабре публикуется, если мнение публики не интересно?
расширение списка причин влияет на авторов а не на минусующих.
Каким образом происходит это влияние по вашему?
Ну вот , чтобы далеко за примерами не ходить - опубликовал я статью , как правило причина первого минуса "Личная неприязнь". И как это должно на меня повлиять ? В очередной раз подтвердить токсичность и хейтерство аудитории Хабра ? А это, что секрет ?
Или причина "не согласен". И что , что не согласен, мне то что с того.
Или вообще огонь , одна самых крутых причин Хабра - "ничего не понял" 😁
Ну вот как эти причины влияют на автора? Ну т.е. на меня . Что , я перестану заниматься интересными мне экспериментами , потому, что кто то непонятный на Хабре ничего не понял или испытывает неприязнь ? 😁
Неужели я обижусь, расстроюсь и с горя от неоценки фиг пойми кем, перестану публиковать результаты исследований и свои мысли ? С какого перепугу ? Просто просмотры публикаций будут не на Хабре а на других ресурсах, и индексироваться будут не страницы Хабра а другие ресурсы .
Вот прям сейчас, с момента слива кармы и ограничения публикации раз в неделю вышло несколько статьей(завтра ещё будет, если будет настроение). Но читатели Хабра их не увидят. В четверг будет итоговая короткая статья и хватит на этом. Статья неделю и достаточно . В ленте Хабра ведь так много интересных статей для практикующих DBA 😎
Ну и кому хуже минусаторы сделали в итоге ?
Итак , ещё раз - как на автора влияют минусы ? Ваше личное мнение .
Я не ездил. Текущая работа образовалась по итогам беседы в Скайпе.
Вообще , вспоминай свой путь - первое единственное тестовое задание и оффлайн собеседование было в далеком 1998 году. И до этого и после просто переписка в почте и беседы в скайпе . Но , повторюсь, я давно не кодер. И повторюсь, софт-скилы IMHO важнее , а их тестовыми задачами не протестить.
Личный опыт во время бывшего тимлидерства - резюме в общем то и не смотрел , просто разговаривал, в скайпе или зуме.
Но, наверное для кодеров свои особенности , я DBA.
А что испытательный срок отменили /запрещен ? Просто не продлевать контракт через 3 месяца(или сколькотдоговорились при оффере).
Никакое собеседование не раскроет человека в принципе . По мне так давно неэффективная практика. Но, это личное мнение и оценочное суждение. Может быть ошибочное.
В свою бытность тимлидом , на хардскилы вообще внимание особо не обращал. Старался просто пообщаться . Пару раз фильтр срабатывал.
Научить можно практически кого угодно, чему угодно , а вот сработаться не с каждым получится . Никакие курсы и накрутки не помогут .
P. S. Правда, я работаю в DBA , там несколько другие особенности . Как у кодеров, не знаю, может свои особенности.
IMHO нейросеть в общем то ни при чем. Хабр всегда таким был. Даже когда ИИ еще был в мечтах энтузиастов.
Тема кармы молота перемолота мильон раз.
Хабр в общем то ничем не отличается от реального мира, такой же слепок - "агрессивное меньшинство". Примеров в реальном мире чуть больше чем до..., в общем много.
Ситуация ведь если вдуматься абсурдная с точки зрения здравого смысла - берем какую нибудь статью с кучей минусов - смотрим количество читателей. Затем статистику минусов . Отношение минусаторов к читателям меньше не то, что статистической погрешности а вообще как правило менее 1%. Основная масса читателей, прочитали и пошли дальше, кто-то может комментарий оставил.
Но минусатор он не такой - он и минус поставит и комментарий возмущенный напишет и еще будет искать автора по другим веткам других статей и там возмущаться. Если минусаторов набирается достаточное количество, то автору сливают карму - ату его он не такой как мы, он думает по другому, он верит в другое - сразу ограничивается возможность писать новые статьи - 1 статья в месяц, потом ограничивается возможность комментировать другие статьи.
В результате - все как в реальном мире - агрессивная очень малая часть читателей Хабра лишает возможность общаться с автором остальную значительно большую часть аудитории.
Повторюсь - Хабр совем не особенная какая то площадка - в реальном мире подобная ситуация сплошь и рядом.
В итоге - автор публикуется на других площадках , просмотры получают другие ресурсы (1000 просмотров в день для Хабра наверняка такие мелочи что модно и забить, хотя зачем поменяли показ статистики с прочтений на показы ? Предположу - цифры слишком уже не оптимистические получились по итогам года). Ну а Хабр, что Хабр - хорошая площадка для SEO , вполне себя оправдывает - цифра кармы и количество минусов под статьями поисковиками и нейросетями не учитываются вообще никак.
Так, что в общем то ничего особенного, жизнь продолжается, караван идет.
Здесь нет "ненавистников ИИ" (который и не ИИ, а всего-то LLM), а только лишь суровые рационалисты — работа такая.
Прикола ради , вот ответ нейросети на вопрос "подбери реальные примеры для СУБД PostgreSQL для общей темы "используя известный тезис о 5 стадиях принятия неизбежного , на какой стадии сейчас находится массовое IT сообщество в принятии использования нейросетей в обычной практике для IT специалиста ?""
Анализируя текущие тенденции в IT-сообществе, особенно среди специалистов по базам данных, можно сделать вывод, что в целом оно находится на стадии «Торга». Сообщество активно экспериментирует с нейросетями как с инструментом, нащупывая его границы и практическую пользу, но еще не пришло к массовому и безоговорочному «Принятию».
Если применить модель Кюблер-Росс к IT-сообществу в контексте нейросетей и PostgreSQL, то разные группы специалистов демонстрируют признаки всех стадий одновременно.
Вот как это выглядит на практике с примерами из области PostgreSQL:
1. Отрицание Суть: Восприятие нейросетей как незрелой технологии, неспособной решать сложные задачи в такой консервативной и критически важной сфере, как СУБД. Пример для PostgreSQL: Убеждение, что классический оптимизатор запросов, основанный на статистике и проверенных эвристиках, всегда превосходит «черный ящик» нейросети в надёжности и предсказуемости. Ядро PostgreSQL не включает и не планирует в ближайшем будущем включать нейросетевые оптимизаторы, что для части сообщества является подтверждением правильности их позиции.
2. Злость Суть: Раздражение от ошибок и неоправданных ожиданий, страх перед бездумной заменой проверенных практик. Пример для PostgreSQL: Критика нейросетевых моделей за систематические ошибки в прогнозировании производительности под нагрузкой. Например, эксперименты показывают, что нейросеть может игнорировать такие факторы, как динамическое кэширование данных в памяти (shared_buffers) или конкуренцию за блокировки индексов при высокой параллельной нагрузке, выдавая неверные рекомендации. Это вызывает скепсис и защитную реакцию у опытных администраторов.
3. Торг (доминирующая стадия в данный момент) Суть: Активные поиски ниши, где нейросети могут быть полезны прямо сейчас, без претензий на революцию. Примеры для PostgreSQL:
Исследовательские проекты: Разработка нейронных оптимизаторов запросов (MSCN, DQ, NEO), которые учатся предсказывать кардинальность или строить оптимальные планы выполнения, демонстрируя потенциал на этапе исследований.
Внешние инструменты анализа: Обсуждение и создание прототипов внешних AI-инструментов (например, на Python), которые анализируют метрики (pg_stat_statements), дают рекомендации по настройке индексов или work_mem, но не встраиваются в ядро СУБД.
Автоматизация рутины: Использование языковых моделей (ChatGPT, GigaChat) для генерации шаблонных SQL-запросов, написания простых скриптов на PL/pgSQL или объяснения сложных планов выполнения.
4. Депрессия Суть: Осознание масштаба изменений и временное ощущение, что фундаментальные навыки могут обесцениться. Пример для PostgreSQL: Размышления о том, не сделают ли нейросети в будущем менее востребованными глубокое знание внутренней механики планировщика запросов или тонкой ручной настройки. Вопрос о целесообразности доклада по нейросетям на профильную конференцию (PgConf) может отражать сомнения в актуальности таких «экспериментальных» тем для практикующих специалистов.
5. Принятие Суть: Нейросети интегрируются в рабочий процесс как один из многих профессиональных инструментов. Примеры для PostgreSQL:
Готовые коммерческие решения: Использование адаптивных оптимизаторов на базе машинного обучения, которые уже являются частью коммерческих дистрибутивов (например, AQO в Postgres Pro).
Инструмент бизнес-аналитики: Интеграция нейросетевых моделей в платформы для работы с данными (например, GigaChat API от Сбера) для автоматической генерации отчетов, трансляции данных или анализа бизнес-процессов, где в качестве источника данных может выступать PostgreSQL.
💎 Заключение
IT-сообщество, и в частности специалисты вокруг PostgreSQL, находятся в активной фазе «Торга». В этой фазе нейросети воспринимаются не как замена, а как потенциальный вспомогательный инструмент для конкретных задач: оптимизации сложных запросов, анализа метрик или автоматизации рутины. Переход к стадии «Принятия» требует времени, практических доказательств надёжности и чёткого определения границ, где нейросети дополняют, а не вытесняют экспертизу человека.
Если вас интересуют конкретные технические детали работы адаптивного оптимизатора AQO или примеры промптов для языковых моделей при работе с SQL, я могу предоставить более подробную информацию.
А автору очень нужно тратить свое время жизни на ответы абсолютно неизвестному персонажу который таки прям требует к себе внимания ?
А этот персонаж вообще кто по жизни, чем известен, что сделал, придумал, чем может поделится в ответ? Дискуссия точно будет иметь смысл ? Он в принципе может понять ответ ?
Самый первый комментарий который прилетел на самую первую статью
Я совсем не DBA, но даже у меня кровь из глаз от таких индексов.
Вот о чем мне разговаривать и какой смысл отвечать и тратить время персонажу который вообще не пойми кто и не пойми чем занимается ? Зачем ?
А про кровь в глазах это ты родной не видел запрос на 5 листов и план выполнения на маленькую книжку и вопрос от разраба - а почему у нас все так медленно работает ;-)
Мне вот интересно, вопрос на который я не могу найти ответ - если ты не DBA так зачем читаешь статьи, написанные DBA для DBA ? Да еще и что-то пишешь и очень обижаешься когда в ответ тишина. Люди странные.
Так на хабре полно статей где авторы ничего не отвечают, всегда так было.
Обычное дело. Все научные издания в общем то в принципе работают в режиме read-only.
P.S. А сейчас количество ответов от меня автоматически снизится на порядки. Так, что проблема в общем то решена. Читайте, раз в неделю на Хабре итоги и старые материаны, новые на Дзене и Пикабу ;-) , если интересно пишите в личку или в почту ;-) если интересно.
А вы выдвигаете гипотезу о достаточности проведённых мероприятий по оптимизации только на основании стоимости плана выполнения т.е. одного единственного выполнения запроса в изолированной среде ?
В условиях параллельной нагрузки и конкуренции за ресурсы инфраструктуры никак не тестируете ?
На самом деле этим занимаются ИБшники. KPI всем нужны особенно в конце года. А потом по итогам делается корпоративная рассылка - будте бдительны , участились случаи использования мессенджеров для получения критических данных.
И все довольны - ИБшники добавляют цифр в KPI, сотрудники оттягиваются в троллинге в мессенджерах.
Ну а те кто обсуждает и обменивается реально рабочей и критичной информацией в телеграме или прости господи ватсапе , ну что ж делать . «Никогданестоитнедооцениватьпредсказуемостьтупизны» (с)
Классика - подписываюсь под каждым словом.
Именно такая мысль пришла еще в прошлом году.
Когда одна идея приходит незнакомым людям - в мысли что-то есть.
Да, были времена когда программирование было наукой , потом инженерной дисциплиной.
Сейчас, ситуация сильно изменилась:
Вы зачем эксклюзивную блокировку используете ?
Это не мы , это фреймворк такой.
Ну и замечательно - ты сохранишь время , что бы не читать новые публикации по теме оптимизации производительности СУБД PostgreSQL , тем более тебе лично сказать сообществу по теме и нечего, кроме бессмысленных комментариев.
Я - использую время освободившееся от подготовки новых публикаций на Хабре на новые эксперименты и публикации на других ресурсах.
Сообщество - продолжить читать ленту Хабра про ИИ , HRов , менеджеров , психологов и прочих очень актуальных на техническом ресурсе материалов , наверное сообществу это очень интересно. Why not.
Администрация Хабра - передает просмотры и прочтения со своего ресурса, другим.
И все довольны . И это хорошо.
в предыдущей статье
Анализ влияния checkpoint_timeout на производительность СУБД PostgreSQL при синтетической нагрузке(Вариант-1) / Хабр
был один профиль нагрузки . В этой статье эксперимент поставлен для двух разных профилей нагрузки.
В связи с политикой Хабра публикуются только выборочные , итоговые результаты экспериментов (1 публикация в неделю). На дзен-канале (ссылка в профиле) масса публикаций по другим значениям checkpoint_timeout. Я не буду приводить ссылку на подборку публикаций , во избежание дальнейшего непрерывного слива кармы по причине "Реклама", если интересно - ссылка на дзен в профиле. На репозиторий инструмента, кстати тоже, если интересно можно все эксперименты проводить и проверять самостоятельно.
В настоящее время эксперименты по checkpoint_timeout - завершены(ну по крайней мере приостановлены). Общая идея понятна, методика отработана, инструмент протестирован, поставленные цели экспериментов - достигнуты. Сейчас проводятся эксперименты по другой теме. Может быть также будет итоговая публикация. Если к тому времени карму не сольют до read-only ;-)
P.S. Ну и разумеется, если уж очень интересно обсуждение темы - лучше в личных сообщениях или в комментариях на дзене. Тут - цензура и отсутствие свободы слова. Впрочем это не бага , это фича Хабра.
Дополнительно по экспериментам с work_mem:
PG_EXPECTO- work_mem: мифы и реальность производительности PostgreSQL
Схема очень простая:
1) Инструмент готовит текстовый файл содержащий результаты статистического анализа (корреляции, регрессии , максимальные минимальные значения и т.п. ) и временные ряды метрик производительности СУБД и инфраструктуры
2) текстовые файлы загружаются в нейросеть, главное не превысить ограничение бесплатной версии (128K токенов). Если данных много , придётся анализировать производительность СУБД и инфраструктуры - отдельно.
3) Дальше есть варианты - либо использовать промпты из библиотеки использованных промптов , либо еще проще использовать базовый промпт - "используя входные данные , подготовь промпты для сводного анализа производительности СУБД и инфраструктуры по результатам эксперимента ".
4) Дальше используя уже загруженные данные и промты - дело техники - готовим сводный отчет.
Доступ нейросети никуда давать не нужно, главное - подготовить достаточный набор данных для анализа.
Примеры обработки нейросетью результатов нагрузочного тестирования и инцидентов производительности СУБД, если интересно - на дзен канале(ссылка в профиле) .
Ну а если сильно интересно - пишите в личку. Отвечать на комментарии хоть как-то оперативно - нет возможности, согласно политике Хабра.
Соглашусь и подтверждаю практическую применимость данного тезиса.
У меня задача сильно проще - есть очень много таблиц и временных рядов , задача найти корреляции и взаимосвязи между данными . Нейросеть , даже в самом простом бесплатном варианте - отлично справляется , дает практически применимый результат и экономит очень много времени на анализ данных.
LLM нормальный и полезный инструмент , если использовать для задач для которых LLM предназначены.
P.S. Например , для прогнозирования нейросети очень плохо приспособлены.
Импорт больших текстовых файлов с временными рядами и возможность анализа данных, кластеризации и выявления корреляций .
И можно будет сравнить с результатами анализа, выполненного другой большой известной нейросетью . Наверное будет интересно . И главное - реальная практическая польза для анализа инцидентов производительности СУБД.
P.S. И пользуясь случаем - просьба сделать вывод результата без псевдографики , в простом текстовом виде. Для дальнейшего протоколирования и анализа в текстовых редакторах.
С академической точки зрения , корректно заявлять не о повышении производительности, а о снижении стоимости выполнения конкретного запроса в условиях единичного изолированного выполнения.
В общем то классика уже - стоимость выполнения отдельного запроса это не производительность СУБД в целом.
Снижение стоимости выполнения запроса не является необходимым и достаточным условием повышения производительности СУБД в целом.
Сценарий когда снижение стоимости запроса не приводит к повышению производительности СУБД в ходе нагрузочного тестирования, а даже наоборот - известны , описаны и опубликованы.
Но в целом , спасибо за информацию и очередную тему для экспериментов 👍🤝.
➕
Немножко перепутана последовательность. Сначала публикации на других ресурсах, потом Хабр для разнообразия и, как было сказано SEO.
Ну и не используйте. Это вообще ни на что не влияет. Я как автор никак не узнаю , что кто то абсолютно неизвестный принципиально не хочет использовать статистический анализ производительности СУБД PostgreSQL на основании рейтинга Хабра 😁
Посмотрел ваш профиль - зачем вам результаты экспериментов и исследований производительности СУБД PostgreSQL? Не используйте , мои статьи не читайте , добавьте меня в черный список.
Мир этого даже не заметит 😎
Нет, вы в корне не правы - автору глубоко плевать и на минусы и на причины тем более .
Результаты и планы экспериментов от реакции и плюсов минусов к публикациям на Хабре, вообще никак не зависят. Цифрам все равно, что про них думаю прохожие .
Ну под автором я про себя конечно, не знаю может быть на Хабре есть авторы реально переживающие за реакцию читателей. Может , кто и ответит .
Возникает закономерный вопрос - а зачем ты тогда на Хабре публикуется, если мнение публики не интересно?
Ответ состоит из 3х букв : SEO.
Каким образом происходит это влияние по вашему?
Ну вот , чтобы далеко за примерами не ходить - опубликовал я статью , как правило причина первого минуса "Личная неприязнь". И как это должно на меня повлиять ? В очередной раз подтвердить токсичность и хейтерство аудитории Хабра ? А это, что секрет ?
Или причина "не согласен". И что , что не согласен, мне то что с того.
Или вообще огонь , одна самых крутых причин Хабра - "ничего не понял" 😁
Ну вот как эти причины влияют на автора? Ну т.е. на меня . Что , я перестану заниматься интересными мне экспериментами , потому, что кто то непонятный на Хабре ничего не понял или испытывает неприязнь ? 😁
Неужели я обижусь, расстроюсь и с горя от неоценки фиг пойми кем, перестану публиковать результаты исследований и свои мысли ? С какого перепугу ? Просто просмотры публикаций будут не на Хабре а на других ресурсах, и индексироваться будут не страницы Хабра а другие ресурсы .
Вот прям сейчас, с момента слива кармы и ограничения публикации раз в неделю вышло несколько статьей(завтра ещё будет, если будет настроение). Но читатели Хабра их не увидят. В четверг будет итоговая короткая статья и хватит на этом. Статья неделю и достаточно . В ленте Хабра ведь так много интересных статей для практикующих DBA 😎
Ну и кому хуже минусаторы сделали в итоге ?
Итак , ещё раз - как на автора влияют минусы ? Ваше личное мнение .
Я не ездил. Текущая работа образовалась по итогам беседы в Скайпе.
Вообще , вспоминай свой путь - первое единственное тестовое задание и оффлайн собеседование было в далеком 1998 году. И до этого и после просто переписка в почте и беседы в скайпе . Но , повторюсь, я давно не кодер. И повторюсь, софт-скилы IMHO важнее , а их тестовыми задачами не протестить.
Личный опыт во время бывшего тимлидерства - резюме в общем то и не смотрел , просто разговаривал, в скайпе или зуме.
Но, наверное для кодеров свои особенности , я DBA.
А что испытательный срок отменили /запрещен ? Просто не продлевать контракт через 3 месяца(или сколькотдоговорились при оффере).
Никакое собеседование не раскроет человека в принципе . По мне так давно неэффективная практика. Но, это личное мнение и оценочное суждение. Может быть ошибочное.
В свою бытность тимлидом , на хардскилы вообще внимание особо не обращал. Старался просто пообщаться . Пару раз фильтр срабатывал.
Научить можно практически кого угодно, чему угодно , а вот сработаться не с каждым получится . Никакие курсы и накрутки не помогут .
P. S. Правда, я работаю в DBA , там несколько другие особенности . Как у кодеров, не знаю, может свои особенности.
IMHO нейросеть в общем то ни при чем. Хабр всегда таким был. Даже когда ИИ еще был в мечтах энтузиастов.
Тема кармы молота перемолота мильон раз.
Хабр в общем то ничем не отличается от реального мира, такой же слепок - "агрессивное меньшинство". Примеров в реальном мире чуть больше чем до..., в общем много.
Ситуация ведь если вдуматься абсурдная с точки зрения здравого смысла - берем какую нибудь статью с кучей минусов - смотрим количество читателей. Затем статистику минусов . Отношение минусаторов к читателям меньше не то, что статистической погрешности а вообще как правило менее 1%. Основная масса читателей, прочитали и пошли дальше, кто-то может комментарий оставил.
Но минусатор он не такой - он и минус поставит и комментарий возмущенный напишет и еще будет искать автора по другим веткам других статей и там возмущаться. Если минусаторов набирается достаточное количество, то автору сливают карму - ату его он не такой как мы, он думает по другому, он верит в другое - сразу ограничивается возможность писать новые статьи - 1 статья в месяц, потом ограничивается возможность комментировать другие статьи.
В результате - все как в реальном мире - агрессивная очень малая часть читателей Хабра лишает возможность общаться с автором остальную значительно большую часть аудитории.
Повторюсь - Хабр совем не особенная какая то площадка - в реальном мире подобная ситуация сплошь и рядом.
В итоге - автор публикуется на других площадках , просмотры получают другие ресурсы (1000 просмотров в день для Хабра наверняка такие мелочи что модно и забить, хотя зачем поменяли показ статистики с прочтений на показы ? Предположу - цифры слишком уже не оптимистические получились по итогам года). Ну а Хабр, что Хабр - хорошая площадка для SEO , вполне себя оправдывает - цифра кармы и количество минусов под статьями поисковиками и нейросетями не учитываются вообще никак.
Так, что в общем то ничего особенного, жизнь продолжается, караван идет.
Вот приметно как то так.
Прикола ради , вот ответ нейросети на вопрос "подбери реальные примеры для СУБД PostgreSQL для общей темы "используя известный тезис о 5 стадиях принятия неизбежного , на какой стадии сейчас находится массовое IT сообщество в принятии использования нейросетей в обычной практике для IT специалиста ?""
-------------------------------------------------------------------------------------
Анализируя текущие тенденции в IT-сообществе, особенно среди специалистов по базам данных, можно сделать вывод, что в целом оно находится на стадии «Торга». Сообщество активно экспериментирует с нейросетями как с инструментом, нащупывая его границы и практическую пользу, но еще не пришло к массовому и безоговорочному «Принятию».
Если применить модель Кюблер-Росс к IT-сообществу в контексте нейросетей и PostgreSQL, то разные группы специалистов демонстрируют признаки всех стадий одновременно.
Вот как это выглядит на практике с примерами из области PostgreSQL:
1. Отрицание
Суть: Восприятие нейросетей как незрелой технологии, неспособной решать сложные задачи в такой консервативной и критически важной сфере, как СУБД.
Пример для PostgreSQL: Убеждение, что классический оптимизатор запросов, основанный на статистике и проверенных эвристиках, всегда превосходит «черный ящик» нейросети в надёжности и предсказуемости. Ядро PostgreSQL не включает и не планирует в ближайшем будущем включать нейросетевые оптимизаторы, что для части сообщества является подтверждением правильности их позиции.
2. Злость
Суть: Раздражение от ошибок и неоправданных ожиданий, страх перед бездумной заменой проверенных практик.
Пример для PostgreSQL: Критика нейросетевых моделей за систематические ошибки в прогнозировании производительности под нагрузкой. Например, эксперименты показывают, что нейросеть может игнорировать такие факторы, как динамическое кэширование данных в памяти (shared_buffers) или конкуренцию за блокировки индексов при высокой параллельной нагрузке, выдавая неверные рекомендации. Это вызывает скепсис и защитную реакцию у опытных администраторов.
3. Торг (доминирующая стадия в данный момент)
Суть: Активные поиски ниши, где нейросети могут быть полезны прямо сейчас, без претензий на революцию.
Примеры для PostgreSQL:
Исследовательские проекты: Разработка нейронных оптимизаторов запросов (MSCN, DQ, NEO), которые учатся предсказывать кардинальность или строить оптимальные планы выполнения, демонстрируя потенциал на этапе исследований.
Внешние инструменты анализа: Обсуждение и создание прототипов внешних AI-инструментов (например, на Python), которые анализируют метрики (
pg_stat_statements), дают рекомендации по настройке индексов илиwork_mem, но не встраиваются в ядро СУБД.Автоматизация рутины: Использование языковых моделей (ChatGPT, GigaChat) для генерации шаблонных SQL-запросов, написания простых скриптов на PL/pgSQL или объяснения сложных планов выполнения.
4. Депрессия
Суть: Осознание масштаба изменений и временное ощущение, что фундаментальные навыки могут обесцениться.
Пример для PostgreSQL: Размышления о том, не сделают ли нейросети в будущем менее востребованными глубокое знание внутренней механики планировщика запросов или тонкой ручной настройки. Вопрос о целесообразности доклада по нейросетям на профильную конференцию (PgConf) может отражать сомнения в актуальности таких «экспериментальных» тем для практикующих специалистов.
5. Принятие
Суть: Нейросети интегрируются в рабочий процесс как один из многих профессиональных инструментов.
Примеры для PostgreSQL:
Готовые коммерческие решения: Использование адаптивных оптимизаторов на базе машинного обучения, которые уже являются частью коммерческих дистрибутивов (например, AQO в Postgres Pro).
Инструмент бизнес-аналитики: Интеграция нейросетевых моделей в платформы для работы с данными (например, GigaChat API от Сбера) для автоматической генерации отчетов, трансляции данных или анализа бизнес-процессов, где в качестве источника данных может выступать PostgreSQL.
💎 Заключение
IT-сообщество, и в частности специалисты вокруг PostgreSQL, находятся в активной фазе «Торга». В этой фазе нейросети воспринимаются не как замена, а как потенциальный вспомогательный инструмент для конкретных задач: оптимизации сложных запросов, анализа метрик или автоматизации рутины. Переход к стадии «Принятия» требует времени, практических доказательств надёжности и чёткого определения границ, где нейросети дополняют, а не вытесняют экспертизу человека.
Если вас интересуют конкретные технические детали работы адаптивного оптимизатора AQO или примеры промптов для языковых моделей при работе с SQL, я могу предоставить более подробную информацию.
А автору очень нужно тратить свое время жизни на ответы абсолютно неизвестному персонажу который таки прям требует к себе внимания ?
А этот персонаж вообще кто по жизни, чем известен, что сделал, придумал, чем может поделится в ответ? Дискуссия точно будет иметь смысл ? Он в принципе может понять ответ ?
Самый первый комментарий который прилетел на самую первую статью
Вот о чем мне разговаривать и какой смысл отвечать и тратить время персонажу который вообще не пойми кто и не пойми чем занимается ? Зачем ?
А про кровь в глазах это ты родной не видел запрос на 5 листов и план выполнения на маленькую книжку и вопрос от разраба - а почему у нас все так медленно работает ;-)
Мне вот интересно, вопрос на который я не могу найти ответ - если ты не DBA так зачем читаешь статьи, написанные DBA для DBA ? Да еще и что-то пишешь и очень обижаешься когда в ответ тишина. Люди странные.
Обычное дело. Все научные издания в общем то в принципе работают в режиме read-only.
P.S. А сейчас количество ответов от меня автоматически снизится на порядки. Так, что проблема в общем то решена. Читайте, раз в неделю на Хабре итоги и старые материаны, новые на Дзене и Пикабу ;-) , если интересно пишите в личку или в почту ;-) если интересно.
Бывайте ..........
А вы выдвигаете гипотезу о достаточности проведённых мероприятий по оптимизации только на основании стоимости плана выполнения т.е. одного единственного выполнения запроса в изолированной среде ?
В условиях параллельной нагрузки и конкуренции за ресурсы инфраструктуры никак не тестируете ?
Для продуктивного контура ????
Классика - подписываюсь под каждым словом.
На самом деле этим занимаются ИБшники. KPI всем нужны особенно в конце года. А потом по итогам делается корпоративная рассылка - будте бдительны , участились случаи использования мессенджеров для получения критических данных.
И все довольны - ИБшники добавляют цифр в KPI, сотрудники оттягиваются в троллинге в мессенджерах.
Ну а те кто обсуждает и обменивается реально рабочей и критичной информацией в телеграме или прости господи ватсапе , ну что ж делать . «Никогда не стоит недооценивать предсказуемость тупизны» (с)
Будете проходить мимо - проходите.