Если я с помощью модели могу сделать код более энергоэффективным, и тратить сильно меньше сил/времени/денег на те же фичи, то какая разница, что кто-то станет богаче? Вроде бы жажда лучшей жизни, известности, и есть часто двигатель прогресса, нет?
А если по-крупному: повышая продуктивность мы можем направить наши усилия туда, где сейчас дефицит: в новые зелёные технологии, космос, что-то ещё. Это ли не круто?
Посмотрим. Собственно, будет любопытно посмотреть, что будет с энтерпрайзами. Пока что в моём опыте - когда пишешь что-то для закрытого продукта, даже если в базе лежит код Postgres, то качество сильно хуже и галлюцинаций сильно больше.
Если то же но в OSS модели можно будет сделать сильно дешевле и в XXX раз быстрее, то может и модель продаж найдётся?
Государственное влияние я признаться за серьезный (ну или иными словами полезный, долговременный) фактор не считаю.
Не знаю насчет трансмиссии, но велик для ребенка, который занимается триатлоном я подбирал в Клоде. Без него я бы точно купил что-то либо маркетинговое, либо дорогое. А так нашёл классное сочетание цена/качество. При том, что сам всю жизнь биатлонист, и про велосипеды знаю почти ничего.
Полагаю, что подбор компонентов трансмиссии требуется профессионалу, а он знает правильные слова для промпта, равно как и способы проконтролировать результат. А вот тот факт, что это приходится делать на сайте магазина на Испанском или Тайском языке - сильно усложняет ситуацию без AI.
Площадка в моём понимании - то же, что и для текущих PGConf/PGDay - активные менеджеры от нескольких компаний выбивают бюджет из этих компаний, находят волонтёров и организуют мероприятие. Физически - это может быть на базе любой из компаний - я бывал в AWS большом офисе, оракловом, на базе университета Ханоя - почти у каждой компании есть headquarters в стране, где достаточно инфраструктуры на 100 оффлайновых человек. Да даже офис Adyen в Мадриде может переварить сильно больше, было бы желание, а стоит копейки.
Количество онлайновых при этом должно масштабироваться достаточно легко.
Что там сейчас в РФ, я не знаю. Может действительно какой-то треш - это выше моего понимания. Если уж в универе собрать митап нельзя, то о каких инновациях, разработках, технологиях можно говорить вообще? Ведь формат "Шарашки" требует запрета на выезд для начала ;).
Хм, а при чем здесь зарубеж? Они гораздо более консервативны в смысле формата. Я планирую написать может через неделю, как организуется PGCOnf.EU - взгляд изнутри программного комитета. Попробую показать, как неудобно и ограниченно там всё устроено.
Размер аудитории мало заботит - эта потребность исходит из необходимости делать OSS проекты и как-то договариваться по сложным вопросам +/- быстро. В постгрессовом сообществе из-за слабой коммуникации часто проекты стоят по нескольку лет. Предложенное организовать несложно и недорого, была бы площадка.
То, что такой формат зайдет техническому сообществу - это к гадалке не ходи. Сейчас офисной работы днём с огнём не сыщешь, как и компенсации поездок. Так что какая-то форма коммуникации, похожая на живой формат очевидно напрашивается. Ну и мультиязычность туда же: например, на испаноязычных конфах по БД весьма интересно - у них нативная проблема с кросс-континентальными конфигурациями и большими latency просто в силу географии - эта штука достаточно уникальна, но язык ради этого учить не будешь.
Хмм. Вся суть техники 'Sort Pushdown' заключается именно в этом - ранняя выборка данных и метод сортировки, эффективный для соотношения лимита и объёма выборки. Я же и картинки старался рисовать, чтобы публике проще было понять.
Это конечно же укор мне, что читатель не понял базовых основ обсуждаемого предмета. Но вот вопрос: а может тогда и всё выше обсужденное в комментариях также лишь результат тотального непонимания?
Если подзапрос нельзя трансформировать в JOIN, то и о его селективности планировщик ничего не знает
Это совсем неверно. Если у него наверху не агрегат, то статистика будет ровно та же, что и если бы не было подзапроса - вычисление селективности умеет в рекурсию.
В данном случае - по CASE. Причем пользы от такой статистики будет намного больше, чем от статистики только по item_id
Возможно это и верно где-нибудь в SQL Server, но в мире Postgres я бы не рокемендовал так делать. Статистика по выражениям конечно возможна - как через функциональный индекс, так и через расширенную статистику, но уж очень лимитировано её применение, и всё ломается при малейшем изменении внутри такого выражения.
Во-первых, если в таблице order_lines миллиард строк, то станет только хуже
Когда нужно выбрать N элементов, то быстрая сортировка сильно хуже heap sort - по крайней мере, я пока верю учебнику по алгоритмам ;)
для поддержки 1С они сделали в разы больше, чем кто-либо другой.
Это было восемь лет назад. Уважаем, но продуктивнее смотреть на тех, кто сейчас активно учит PG работать с ORM
Спасибо за отзыв и примеры. В целом здесь больше не о чем говорить, поскольку кейсы совсем разные:
ручной тюнинг запросов с такими объемами облачных баз, клиентов и приложений я не рассматриваю. Увы, XXI век в разгаре.
Ежели бы ручной тюнинг был настолько актуален, то в ПГ почти не нужны были бы как подбор порядка джойнов, так и всякие pull-up subplan - делай все без подпланов и будет счастье ;)
CASE использовать - это точно опасный подход, годящийся для вручную управляемой БД - таких кейсов у меня не бывает.
Люди приходят ко мне часто, когда на таблице с 1E9 строк сканирование сваливается в неудачный IndexScan или SeqScan и запрос выполняется секунды, на не мс. Ситуация часто зависит от константы и только cost-based подход позволяет решать, что лучше в конкретном случае. Любые варианты трансформации запроса - точно не про это. pushdown Sort равно как перенос подзапроса поближе к исходной таблице - все это регулируется костами.
Для игрального сервера, которому в сумме надо переживать ~14 миллионов строк - вполне нормально.
Хм, мои клиенты не любят ждать больше 500мс ;) И им все равно, какой размер базы.
Так тут и разницы не увидите в любом случае, так как она окажется в пределах 10 мс.
Хех, так о том и речь, что неоптимальный запрос сканирует 1E9 строк, чтобы выдать сотню. Конечно же увидим, и огромный - затем и развиваем оптимизатор.
кто запрещает так переписать запрос?
Видимо миры у нас разные. Обычно нет такого понятия как переписать запрос в системах, где все построено на драйверах баз данных, rest API, а теперь ещё и AI-generators
проблемы 1С не встречают активного отклика в PostgreSQL community
1C и правда не встречает, но я и использую его только для русскоязычного сообщества. На английском языке я упоминаю SalesForce, SAP, всякие CRM, Django, Hibernate ... А там уже и реакция приходит.
очень часто, остаются в пределах Postgres Pro
Вспомнили динозавра! Вроде ж они всё больше про маркетинг последнее время - деньги, штука важная - только мы тут технологии обсуждаем.
В целом, всегда есть компромисс между исправлением приложения и развитием оптимизатора. И он лежит в сложности доработки и поддержки кода. Указанные в тексте доработки достаточно просты, так что судьба двух из них кажется мне вполне перпективной.
Как по мне, то 5 секунд - это тоже очень плохо, если только запросу не нужно для аналитики действительно поднять миллионы строк.
Мой пост всё-таки для случаев, где реальное количество данных, нужное для построения ответа, невелико. И выстраивание оптимального плана ускоряет такие запросы на порядки - просто за счет того, что вместо многократного сканирования многих таблиц можно ограничиться точечным обращением по месту. И что важно - эстимации оптимизатора не ухудшаются, а где-то даже и улучшаются. Ведь это важно, чтобы оптимизатор подобрал оптимальный способ джойна, сортировки или группировки?
Если убрать аргумент с негибкой 1С, то я бы просто не рекомендовал увеличивать количество CASE конструкций в Postgres-системах. Да, оно может помочь. Но стоит помнить, что статистика по CASE выражению - это просто магическое число. А значит, выше по дереву запроса всё будет сильно хуже с эстимациями.
В базе такой подход уменьшает предсказуемость выбора плана запроса оптимизатором. Кому как, а я на такое пошёл бы только в случае крайней нужды.
Если это про переписывание запроса - то 1С (да и другие CRM-ки) тихо смеётся в сторонке. Да и переписывая мы действительно, делаем конкретные кейсы эффективнее, но помним, что в ПГ есть разнообразие вариантов планирования джойнов - что делает план гибче, в случае изменения профиля данных.
В книге с правилами ГИБДД используется удобный приём - новый текст выделен одним шрифтом, а изменённый - другим. Это позволяет быстро отследить изменения с предыдущей редакции. Postgres в этом смысле весьма похож - было бы удобно, чтобы не читать каждый раз всё заново.
здесь важно отметить: что конкретно нужно развивать в постгресе зависит от характера нагрузки: нужно ли сагрегировать весь массив данных или поселектить только малую часть?
Если первое - то нужно изобретать executor для columnar storage, что в принципе не особенно сложно. А если второе - то методы параметризованного fdw и статистику по частям таблиц, а-ля snowflake. Это уже совсем другое направление.
Никто тогда ничего не потерял. Но дело может быть просто в Роскосмосе - уволить человека, это прям квест был. Дешевле было оставить и не требовать ничего, чем увольнять. Так что тут стоит смотреть на то, что в итоге отрасль получила - SpaceX и деривативы, нежели негативные стороны. Впрочем, мы ж не знаем, как это изменило инженеров в свободных странах, в той же США. Может у них и были массовые увольнения.
Ага, примерно это мы уде проходили в начале 2010-х, когда в инженерку пришло компьютерное моделирование (аналог AI для инженеров). Тоже хотели всё посчитать и сократить. Потом оказалось, что и вычислительные кластеры чересчур дороги, и для сложных задач требуются либо люди, либо бесконечные по сложности модели ...
Но ничего, нашли компромисс, есть эффект и буст, пусть и не такие ультимативные, которые мы ждали тогда. Вероятно, и с AI нынешним также придётся находить баланс.
В целом любопытно, как так свежий SQL Server хуже старого. Напоминает ситуацию, когда наиболее эффективный инструмент тот, что знаешь лучше всего. Так что интересно будет изучить.
Я просто замечу, что можно изобретать всякие промежуточные методы ограничения количества джйонов в задаче поиска. Фиксированный join_collapse_limit - это только один из путей.
Например вводя гибкий лимит (https://github.com/danolivo/pgdev/tree/resilient-collapse-limit) можно жёстко ограничивать пространство поиска в одном дереве джойнов, но автоматически увеличивать его в запросах, где преобразования дерева запроса (pull-up SubLink и иные причины) расширяют это дерево без команды от пользователя.
Увы, это очень похоже на подход Oracle и DeWitt's Clause. Без сравнения мы не можем узнать - хороша наша СУБД, или мы технологически находимся в позапрошлом веке. А вдруг 1ТБ + 30к пользователей - это уже несерьёзно в области управления данными? Вдруг, для этой задачи хватит виртуалки на одном из серверов, использованных для теста? Понятно, что я утрирую, но мы ж не знаем.
Если я с помощью модели могу сделать код более энергоэффективным, и тратить сильно меньше сил/времени/денег на те же фичи, то какая разница, что кто-то станет богаче? Вроде бы жажда лучшей жизни, известности, и есть часто двигатель прогресса, нет?
А если по-крупному: повышая продуктивность мы можем направить наши усилия туда, где сейчас дефицит: в новые зелёные технологии, космос, что-то ещё. Это ли не круто?
Посмотрим. Собственно, будет любопытно посмотреть, что будет с энтерпрайзами. Пока что в моём опыте - когда пишешь что-то для закрытого продукта, даже если в базе лежит код Postgres, то качество сильно хуже и галлюцинаций сильно больше.
Если то же но в OSS модели можно будет сделать сильно дешевле и в XXX раз быстрее, то может и модель продаж найдётся?
Государственное влияние я признаться за серьезный (ну или иными словами полезный, долговременный) фактор не считаю.
Не знаю насчет трансмиссии, но велик для ребенка, который занимается триатлоном я подбирал в Клоде. Без него я бы точно купил что-то либо маркетинговое, либо дорогое. А так нашёл классное сочетание цена/качество. При том, что сам всю жизнь биатлонист, и про велосипеды знаю почти ничего.
Полагаю, что подбор компонентов трансмиссии требуется профессионалу, а он знает правильные слова для промпта, равно как и способы проконтролировать результат. А вот тот факт, что это приходится делать на сайте магазина на Испанском или Тайском языке - сильно усложняет ситуацию без AI.
Площадка в моём понимании - то же, что и для текущих PGConf/PGDay - активные менеджеры от нескольких компаний выбивают бюджет из этих компаний, находят волонтёров и организуют мероприятие. Физически - это может быть на базе любой из компаний - я бывал в AWS большом офисе, оракловом, на базе университета Ханоя - почти у каждой компании есть headquarters в стране, где достаточно инфраструктуры на 100 оффлайновых человек. Да даже офис Adyen в Мадриде может переварить сильно больше, было бы желание, а стоит копейки.
Количество онлайновых при этом должно масштабироваться достаточно легко.
Что там сейчас в РФ, я не знаю. Может действительно какой-то треш - это выше моего понимания. Если уж в универе собрать митап нельзя, то о каких инновациях, разработках, технологиях можно говорить вообще? Ведь формат "Шарашки" требует запрета на выезд для начала ;).
Хм, а при чем здесь зарубеж? Они гораздо более консервативны в смысле формата. Я планирую написать может через неделю, как организуется PGCOnf.EU - взгляд изнутри программного комитета. Попробую показать, как неудобно и ограниченно там всё устроено.
Размер аудитории мало заботит - эта потребность исходит из необходимости делать OSS проекты и как-то договариваться по сложным вопросам +/- быстро. В постгрессовом сообществе из-за слабой коммуникации часто проекты стоят по нескольку лет. Предложенное организовать несложно и недорого, была бы площадка.
То, что такой формат зайдет техническому сообществу - это к гадалке не ходи. Сейчас офисной работы днём с огнём не сыщешь, как и компенсации поездок. Так что какая-то форма коммуникации, похожая на живой формат очевидно напрашивается. Ну и мультиязычность туда же: например, на испаноязычных конфах по БД весьма интересно - у них нативная проблема с кросс-континентальными конфигурациями и большими latency просто в силу географии - эта штука достаточно уникальна, но язык ради этого учить не будешь.
люди и так и сяк будут присутствовать в цеплчке организации. Вопрос в том, как организовывать.
Бюрократия и ограничения - это приходящее и меня не интересуют: технологии живут дольше политики и влияют больше.
Хмм. Вся суть техники 'Sort Pushdown' заключается именно в этом - ранняя выборка данных и метод сортировки, эффективный для соотношения лимита и объёма выборки. Я же и картинки старался рисовать, чтобы публике проще было понять.
Это конечно же укор мне, что читатель не понял базовых основ обсуждаемого предмета. Но вот вопрос: а может тогда и всё выше обсужденное в комментариях также лишь результат тотального непонимания?
Это совсем неверно. Если у него наверху не агрегат, то статистика будет ровно та же, что и если бы не было подзапроса - вычисление селективности умеет в рекурсию.
Возможно это и верно где-нибудь в SQL Server, но в мире Postgres я бы не рокемендовал так делать. Статистика по выражениям конечно возможна - как через функциональный индекс, так и через расширенную статистику, но уж очень лимитировано её применение, и всё ломается при малейшем изменении внутри такого выражения.
Когда нужно выбрать N элементов, то быстрая сортировка сильно хуже heap sort - по крайней мере, я пока верю учебнику по алгоритмам ;)
Это было восемь лет назад. Уважаем, но продуктивнее смотреть на тех, кто сейчас активно учит PG работать с ORM
Спасибо за отзыв и примеры. В целом здесь больше не о чем говорить, поскольку кейсы совсем разные:
ручной тюнинг запросов с такими объемами облачных баз, клиентов и приложений я не рассматриваю. Увы, XXI век в разгаре.
Ежели бы ручной тюнинг был настолько актуален, то в ПГ почти не нужны были бы как подбор порядка джойнов, так и всякие pull-up subplan - делай все без подпланов и будет счастье ;)
CASE использовать - это точно опасный подход, годящийся для вручную управляемой БД - таких кейсов у меня не бывает.
Люди приходят ко мне часто, когда на таблице с 1E9 строк сканирование сваливается в неудачный IndexScan или SeqScan и запрос выполняется секунды, на не мс. Ситуация часто зависит от константы и только cost-based подход позволяет решать, что лучше в конкретном случае. Любые варианты трансформации запроса - точно не про это. pushdown Sort равно как перенос подзапроса поближе к исходной таблице - все это регулируется костами.
Хм, мои клиенты не любят ждать больше 500мс ;) И им все равно, какой размер базы.
Хех, так о том и речь, что неоптимальный запрос сканирует 1E9 строк, чтобы выдать сотню. Конечно же увидим, и огромный - затем и развиваем оптимизатор.
Видимо миры у нас разные. Обычно нет такого понятия как переписать запрос в системах, где все построено на драйверах баз данных, rest API, а теперь ещё и AI-generators
1C и правда не встречает, но я и использую его только для русскоязычного сообщества. На английском языке я упоминаю SalesForce, SAP, всякие CRM, Django, Hibernate ... А там уже и реакция приходит.
Вспомнили динозавра! Вроде ж они всё больше про маркетинг последнее время - деньги, штука важная - только мы тут технологии обсуждаем.
В целом, всегда есть компромисс между исправлением приложения и развитием оптимизатора. И он лежит в сложности доработки и поддержки кода. Указанные в тексте доработки достаточно просты, так что судьба двух из них кажется мне вполне перпективной.
Как по мне, то 5 секунд - это тоже очень плохо, если только запросу не нужно для аналитики действительно поднять миллионы строк.
Мой пост всё-таки для случаев, где реальное количество данных, нужное для построения ответа, невелико. И выстраивание оптимального плана ускоряет такие запросы на порядки - просто за счет того, что вместо многократного сканирования многих таблиц можно ограничиться точечным обращением по месту. И что важно - эстимации оптимизатора не ухудшаются, а где-то даже и улучшаются. Ведь это важно, чтобы оптимизатор подобрал оптимальный способ джойна, сортировки или группировки?
Если убрать аргумент с негибкой 1С, то я бы просто не рекомендовал увеличивать количество CASE конструкций в Postgres-системах. Да, оно может помочь. Но стоит помнить, что статистика по CASE выражению - это просто магическое число. А значит, выше по дереву запроса всё будет сильно хуже с эстимациями.
В базе такой подход уменьшает предсказуемость выбора плана запроса оптимизатором. Кому как, а я на такое пошёл бы только в случае крайней нужды.
Хм, а я не понял.
Если это про переписывание запроса - то 1С (да и другие CRM-ки) тихо смеётся в сторонке. Да и переписывая мы действительно, делаем конкретные кейсы эффективнее, но помним, что в ПГ есть разнообразие вариантов планирования джойнов - что делает план гибче, в случае изменения профиля данных.
В книге с правилами ГИБДД используется удобный приём - новый текст выделен одним шрифтом, а изменённый - другим. Это позволяет быстро отследить изменения с предыдущей редакции. Postgres в этом смысле весьма похож - было бы удобно, чтобы не читать каждый раз всё заново.
Ага. Только mailing lists так быстро не посмотришь. Да и CFP конференций - извечная проблема отслеживать. А тут оно все автоматизировано.
здесь важно отметить: что конкретно нужно развивать в постгресе зависит от характера нагрузки: нужно ли сагрегировать весь массив данных или поселектить только малую часть?
Если первое - то нужно изобретать executor для columnar storage, что в принципе не особенно сложно. А если второе - то методы параметризованного fdw и статистику по частям таблиц, а-ля snowflake. Это уже совсем другое направление.
Никто тогда ничего не потерял. Но дело может быть просто в Роскосмосе - уволить человека, это прям квест был. Дешевле было оставить и не требовать ничего, чем увольнять. Так что тут стоит смотреть на то, что в итоге отрасль получила - SpaceX и деривативы, нежели негативные стороны. Впрочем, мы ж не знаем, как это изменило инженеров в свободных странах, в той же США. Может у них и были массовые увольнения.
Ага, примерно это мы уде проходили в начале 2010-х, когда в инженерку пришло компьютерное моделирование (аналог AI для инженеров). Тоже хотели всё посчитать и сократить. Потом оказалось, что и вычислительные кластеры чересчур дороги, и для сложных задач требуются либо люди, либо бесконечные по сложности модели ...
Но ничего, нашли компромисс, есть эффект и буст, пусть и не такие ультимативные, которые мы ждали тогда. Вероятно, и с AI нынешним также придётся находить баланс.
А можно ссылку на исследование?
В целом любопытно, как так свежий SQL Server хуже старого. Напоминает ситуацию, когда наиболее эффективный инструмент тот, что знаешь лучше всего. Так что интересно будет изучить.
Я просто замечу, что можно изобретать всякие промежуточные методы ограничения количества джйонов в задаче поиска. Фиксированный join_collapse_limit - это только один из путей.
Например вводя гибкий лимит (https://github.com/danolivo/pgdev/tree/resilient-collapse-limit) можно жёстко ограничивать пространство поиска в одном дереве джойнов, но автоматически увеличивать его в запросах, где преобразования дерева запроса (pull-up SubLink и иные причины) расширяют это дерево без команды от пользователя.
Увы, это очень похоже на подход Oracle и DeWitt's Clause. Без сравнения мы не можем узнать - хороша наша СУБД, или мы технологически находимся в позапрошлом веке. А вдруг 1ТБ + 30к пользователей - это уже несерьёзно в области управления данными? Вдруг, для этой задачи хватит виртуалки на одном из серверов, использованных для теста? Понятно, что я утрирую, но мы ж не знаем.