Comments 9
Не совсем понял, что и, главное, зачем сравниваем? 140 заказчиков - это ни о чем.
Давайте посмотрим более реальный сценарий - 80 филиалов, 20000+ заказчиков, суммарно 1000000 заказов в год, история за 3-5 лет. Задачи:
1) Рассчитать доход от каждого клиента за текущий год по кварталам в разрезе филиалов и суммарно
2) Сравнить с доходами за аналогичные периоды прошлых лет
Мне кажется, это более показательная задача для сравнения. У меня нет PostgreSQL, чтобы провести такое сравнение, но было бы интересно посмотреть...
Аналогичные результаты, подтверждающие нерелевантность гипотез нейросети о более высокой производительности запроса с использованием Join по сравнению с коррелированным подзапросом получены на Демобазе 2.0 (сгенерированная тестовая БД, размер 12GB):
https://dzen.ru/a/aRwqQMQfaV04Qh7r
Статья для Хабра - готовится.
Вообще базово LLM не могут быть идеальными консультантами, зато они могут автоматически итеративно пробовать разные конфигурации без существования человека в этой цепочке. openevolve как инструмент тому хорошее доказательство. Было бы интересно посмотреть каких результатов можно добиться с ним.
А вообще есть ощущение что так называемый AGI в целом недостижим из-за архитектуры самих LLM
А что именно обозначают на вашем графике показатели «Операционная скорость» и «Точка наблюдения»?
Что вы хотели продемонстрировать данной статьёй?
Сам вопрос о том, что лучше — коррелированный подзапрос или JOIN, некорректен, поскольку для каждого запроса и каждого распределения данных ответ может быть разным.
Как будут вести себя ваши запросы, если количество клиентов увеличится?
А если база данных будет размещена не на SSD, а на HDD, и данные не будут находиться в памяти?
А если, помимо подсчёта количества, потребуется вычислять сумму по заказам или появятся дополнительные условия отбора заказов, из‑за которых одного обращения к индексу окажется недостаточно?
что именно обозначают на вашем графике показатели «Операционная скорость» и «Точка наблюдения»?
В контексте оценки производительности СУБД используется метрика «операционная скорость». Данный показатель агрегируется за заданный временной период и представляет собой сумму двух сглаженных компонентов: взвешенного количества SQL-операций и результирующих строк. Процедура сглаживания динамических рядов указанных компонентов основана на применении скользящей медианы с окном в 60 минут. Наблюдения за метрикой фиксируются в дискретные моменты времени(точка наблюдения), соответствующие порядковому номеру минуты в ходе нагрузочного тестирования.
Источники:
Корреляционный анализ ожиданий СУБД PostgreSQL - презентация по докладу, не попавшему на конференцию PGConf.СПб 2025 : https://dzen.ru/a/aJsZb6lzqxEd1KmR
Статистический анализ производительности СУБД PostgreSQL: https://dzen.ru/a/aGYjGIt_KDOjmf35
Какой-то не очевидный коррелированный запрос. Обычно видишь в плане 1 строка и миллион циклов.
Везде пишут что джоин предпочтительней чем коррелированный запрос. Что на курсах септика, что на популярном сайте с счетчиком времени выполнения запросов. Видимо и за границей так, вот ии выдаёт популярный совет.
Везде пишут
В этом то и проблема - все кто пишут никогда не проверяют рекомендации экспериментально . Максимум пару раз выполнить запрос и посмотреть explain.
То, что всё нужно тестировать синтетической нагрузкой , пока воспринимается как ересь.
и за границей так, вот ии выдаёт популярный совет
Да, DeepSeek основывается в основном на публикациях в китайском сегменте интернета. Ответы DeepSeek и "Ask Postgres", например , практически не отличаются.
Хотя DeepSeek иногда все таки выдает эксклюзив .
ИИ как опасный советчик: Почему нейросетям нельзя доверять настройку производительности PostgreSQL