Насчет аппаратной поддержки - это вроде бы пока не мэйнстрим. Как будет - всем станет хорошо.
На самом деле стоимость вычислений numeric (и это частично даже проглядывает в данном тексте) немного в другом. С точки зрения хранения он выгоднее int64/int128 в среднем. Проблема однако в том, что число приходится распаковывать/детостить на каждое использование. Второй фактор - передача по указателю. Из существующих (заброшенных) реализаций можно увидеть, что эффективность точного десятичного, если бы ее ограничить количеством цифр, которые можно представить 8 байтами под число, весьма велика, почти не в чем не уступая обычному int64.
А дальше уже идут вопросы к точности и некоторым другим, уже архитектурным, нюансам. Но прояснение проблем реализации давайте оставим на другой раз.
Ну, тут не про numeric V/S int, а про разумные ограничения numeric. Нам же точно не требуются все 131тыс цифр, которые этот тип обеспечивает? Наверное и 1тыс цифр будет перебором. Тогда сколько? - это ведь напрямую сказывается на производительности ==> потребление ресурсов, а значит потреблении энергии.
Ага. Мне собственно важно понять, какой формат устроит всех, или почти всех. Четыре знака это круто, но сколько там еще до запятой? И важно - какова максимально допустимая величина агрегата? Ведь суммируя 1Е9 трехзначных чисел мы можем получить довольно большое число.
Собственно в этом и кроется рецепт оптимизации -сделать ограниченный numeric, который в идеале будет передаваться по значению, а математические операции не потребуют дополнительных аллокаций памяти.
Да, признаю, я здесь немного недораскрыл посыл, ибо пришлось подсократить текст. numeric уж сильно контрастирует на фоне всего остального - иногда, это и в 10 раз медленнее и сильно больше потребление памяти.
Это плохо, учитывая сколько серверов крутятся на postgres. Это означает чрезмерное потребление энергии, отсюда и посыл выяснить, можно ли с этим бороться. И даже из текста видно, что можно. Ибо новосделанные системы проблему видели с самого начала и подстраивали свою архитектуру в ттм числе и под быстрые точные десятичные.
О, спасибо за наводку! А я всё думал, какие бы примеры привести для англоязычного читателя.
Если бы кому-то нужен был numeric с точностью до 17 цифр, то для PostgreSQL написать такой тип было бы совсем несложно. А ускорение там может измеряться разами на арифметике, а на агрегатах и того больше.
Ну так кто бы инвестировал в разработку хотя бы небольшую долю от SQL Server'ных вливаний. Так ведь нет, все хотят и хорошо, и бесплатно. Так что полагаю этот гэп обусловлен самой структурой бизнесов.
Разве что AI как-то ситуацию изменит - вроде бы он эффективнее на открытых, хорошо структурированных кодах, чем на всякой лапше, свойственной энтерпрайзам ... .
Ты наверняка верстаешь в тех или еще чем-то форматируемом стилями. Так что ответ очевиден - ввести стиль для изменений и иметь хоть несколько разных pdf - с выделением и без. Так можно и несколько уровней изменений накрутить. В общем - было бы желание …
Это здорово, что компании из РФ пытаются контрибьютить в коммьюнити такие ивенты!
Единственное, что неочевидно - место проведения. Непал - это больше для Юго-восточной Азии, Индии, может Тайваня. Для Европы и Америк - это слишком дорого - как перелёт, так и нахождение. Всё-ж таки место туристическое, высокогорное, требует некоторой подготовки. Основная часть сообщества находится немного в другой локации и даже Турция выглядит логичнее.
Однако, у меня в корпоративном аккаунте Claude есть такая фича, скиллы и дообучение были сделаны. И я всё-таки наблюдаю, что количество шагов, сложность промпта и объемы ошибочного кода сильно больше, чем для ваниллы. Видимо, эти extra знания не интегрируются в общую LLM модель или сказывается отсутствие 30 летней истории подробных дискуссий об архитектуре принимаемых решений. В общем, будем наблюдать - пока технология в развитии.
Если я с помощью модели могу сделать код более энергоэффективным, и тратить сильно меньше сил/времени/денег на те же фичи, то какая разница, что кто-то станет богаче? Вроде бы жажда лучшей жизни, известности, и есть часто двигатель прогресса, нет?
А если по-крупному: повышая продуктивность мы можем направить наши усилия туда, где сейчас дефицит: в новые зелёные технологии, космос, что-то ещё. Это ли не круто?
Посмотрим. Собственно, будет любопытно посмотреть, что будет с энтерпрайзами. Пока что в моём опыте - когда пишешь что-то для закрытого продукта, даже если в базе лежит код 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 равно как перенос подзапроса поближе к исходной таблице - все это регулируется костами.
Помимо прочего, это запрещено на уровне регламентов, как собственно показано в статье.
Насчет аппаратной поддержки - это вроде бы пока не мэйнстрим. Как будет - всем станет хорошо.
На самом деле стоимость вычислений numeric (и это частично даже проглядывает в данном тексте) немного в другом. С точки зрения хранения он выгоднее int64/int128 в среднем. Проблема однако в том, что число приходится распаковывать/детостить на каждое использование. Второй фактор - передача по указателю. Из существующих (заброшенных) реализаций можно увидеть, что эффективность точного десятичного, если бы ее ограничить количеством цифр, которые можно представить 8 байтами под число, весьма велика, почти не в чем не уступая обычному int64.
А дальше уже идут вопросы к точности и некоторым другим, уже архитектурным, нюансам. Но прояснение проблем реализации давайте оставим на другой раз.
Ну, тут не про numeric V/S int, а про разумные ограничения numeric. Нам же точно не требуются все 131тыс цифр, которые этот тип обеспечивает? Наверное и 1тыс цифр будет перебором. Тогда сколько? - это ведь напрямую сказывается на производительности ==> потребление ресурсов, а значит потреблении энергии.
Ага. Мне собственно важно понять, какой формат устроит всех, или почти всех. Четыре знака это круто, но сколько там еще до запятой? И важно - какова максимально допустимая величина агрегата? Ведь суммируя 1Е9 трехзначных чисел мы можем получить довольно большое число.
Собственно в этом и кроется рецепт оптимизации -сделать ограниченный numeric, который в идеале будет передаваться по значению, а математические операции не потребуют дополнительных аллокаций памяти.
Да, признаю, я здесь немного недораскрыл посыл, ибо пришлось подсократить текст. numeric уж сильно контрастирует на фоне всего остального - иногда, это и в 10 раз медленнее и сильно больше потребление памяти.
Это плохо, учитывая сколько серверов крутятся на postgres. Это означает чрезмерное потребление энергии, отсюда и посыл выяснить, можно ли с этим бороться. И даже из текста видно, что можно. Ибо новосделанные системы проблему видели с самого начала и подстраивали свою архитектуру в ттм числе и под быстрые точные десятичные.
Рекомендовать то, что плохо работает - вот что не согласуется.
Здесь цель была другая. Мне сначала важно было понять, нельзя ли вообще отказаться от точных десятичных. И если нет, то какие ограничения сузествуют.
А про что делать - это уже следующий этап
О, спасибо за наводку! А я всё думал, какие бы примеры привести для англоязычного читателя.
Если бы кому-то нужен был numeric с точностью до 17 цифр, то для PostgreSQL написать такой тип было бы совсем несложно. А ускорение там может измеряться разами на арифметике, а на агрегатах и того больше.
Ну так кто бы инвестировал в разработку хотя бы небольшую долю от SQL Server'ных вливаний. Так ведь нет, все хотят и хорошо, и бесплатно. Так что полагаю этот гэп обусловлен самой структурой бизнесов.
Разве что AI как-то ситуацию изменит - вроде бы он эффективнее на открытых, хорошо структурированных кодах, чем на всякой лапше, свойственной энтерпрайзам ... .
Ты наверняка верстаешь в тех или еще чем-то форматируемом стилями. Так что ответ очевиден - ввести стиль для изменений и иметь хоть несколько разных pdf - с выделением и без. Так можно и несколько уровней изменений накрутить. В общем - было бы желание …
Это здорово, что компании из РФ пытаются контрибьютить в коммьюнити такие ивенты!
Единственное, что неочевидно - место проведения. Непал - это больше для Юго-восточной Азии, Индии, может Тайваня. Для Европы и Америк - это слишком дорого - как перелёт, так и нахождение. Всё-ж таки место туристическое, высокогорное, требует некоторой подготовки. Основная часть сообщества находится немного в другой локации и даже Турция выглядит логичнее.
Может быть, здесь я не сварщик.
Однако, у меня в корпоративном аккаунте Claude есть такая фича, скиллы и дообучение были сделаны. И я всё-таки наблюдаю, что количество шагов, сложность промпта и объемы ошибочного кода сильно больше, чем для ваниллы. Видимо, эти extra знания не интегрируются в общую LLM модель или сказывается отсутствие 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 равно как перенос подзапроса поближе к исходной таблице - все это регулируется костами.