Ok,выглядит так, что прежде чем делать выводы нужно таки увидеть хотя бы общую архитектуру решения, поскольку каждый ответ порождает только больше вопросов, вызванных незнанием конкретного устройства механизма сжатия и размещения сжатых страниц на диске.
Всё бы хорошо, но мне не хватает прояснения двух аспектов:
Явно озвученный компромисс. Очевидно, что у всех аппаратная начинка разная. Поэтому, что здесь будет определяющим фактором: баланс между затратами CPU на сжатие и позитивным IO эффектом? Или здесь ещё важно соотношение между DML и SELECT?
Что с оптимизацией. Очевидно, что любая компрессия аффектит размер таблицы, наверняка оценку пустого пространства и точно - реальные косты на чтение / запись страниц, так? Значит и планы поплывут, либо эффективность планов изменится. Итого, что получается по эффективности планирования до и после сжатия? Трёхкратное изменение размера - это много.
Насчет аппаратной поддержки - это вроде бы пока не мэйнстрим. Как будет - всем станет хорошо.
На самом деле стоимость вычислений 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 просто в силу географии - эта штука достаточно уникальна, но язык ради этого учить не будешь.
Ok,выглядит так, что прежде чем делать выводы нужно таки увидеть хотя бы общую архитектуру решения, поскольку каждый ответ порождает только больше вопросов, вызванных незнанием конкретного устройства механизма сжатия и размещения сжатых страниц на диске.
Всё бы хорошо, но мне не хватает прояснения двух аспектов:
Явно озвученный компромисс. Очевидно, что у всех аппаратная начинка разная. Поэтому, что здесь будет определяющим фактором: баланс между затратами CPU на сжатие и позитивным IO эффектом? Или здесь ещё важно соотношение между DML и SELECT?
Что с оптимизацией. Очевидно, что любая компрессия аффектит размер таблицы, наверняка оценку пустого пространства и точно - реальные косты на чтение / запись страниц, так? Значит и планы поплывут, либо эффективность планов изменится. Итого, что получается по эффективности планирования до и после сжатия? Трёхкратное изменение размера - это много.
Помимо прочего, это запрещено на уровне регламентов, как собственно показано в статье.
Насчет аппаратной поддержки - это вроде бы пока не мэйнстрим. Как будет - всем станет хорошо.
На самом деле стоимость вычислений 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 просто в силу географии - эта штука достаточно уникальна, но язык ради этого учить не будешь.
люди и так и сяк будут присутствовать в цеплчке организации. Вопрос в том, как организовывать.
Бюрократия и ограничения - это приходящее и меня не интересуют: технологии живут дольше политики и влияют больше.