Да, держать на стороне СУБД кэш результатов конкретных запросов - это странная идея. Вот автоматом создавать MATERIALIZED VIEW, чтобы потом их использовать в других запросах - вот это была бы тема!
Здесь самый главный вопрос даже не инвалидация кэша, а насколько часто в БД встречаются абсолютно идентичные запросы, с идентичными константами? Если часто, то может приложению стоит просто самостоятельно запомнить результат?
Ну и да, зависимость от вероятности попасть на коллизию хэшей врядли добавляет DBA спокойствия …
Так вроде ж специально выставляют этот лимит так высоко, чтобы GEQO включился и до 20 джойнов находил разумные комбинации вместо слепого следования синтаксическому порядку, нет?
Ну так вот и хотелось бы конкретики, а не просто слов. Каков главный радиус, как сделаны баки , схемы пайки, чем отличаются гаргроты, силовые кольца, двигатели и их крепления ... . Как минимум одна общая деталь есть - движок 170/171/180/190 - всё та же технология. Пусть и проверенная и надёжная, но та же. То есть не спроектированная нативно под современные материалы/3D печать и прочее.
В целом всё лучше, чем ничего. Как минимум новая версия носителя означает новое КД, новые инвентарные номера в спецархиве, что хорошо, поскольку старое имеет тенденцию теряться.
Но было бы гораздо интереснее и полезнее увидеть сравнение этого Союз-5 с советским предшественником - ну хотя бы крупноузловой анализ, если у автора есть соответствующий материал и компетенции.
Вот только Байтерек непонятно причём здесь. Так-то это был (насколько я помню) проект по заказу Казахстана - создание их собственного носителя для собственного космодрома. Но уже тогда ходили разговоры, что деньги Роскосмос просто проест и предложит что-то готовое с минимальными модификациями. Так что любопытно изучить, что в итоге получилось, чем нынешний союз принципиально отличается от старых. Уж теплозащиту и электронику давно бы следовало обновить.
ИИ агенты эффективно анализируют код уже с полгода. За такой срок для такого широко используемого сервиса как GitHub всего один CVE - это прям успех и показатель качества работы инженеров этой платформы.
Ну, четвертое измерение в логике функций имеет скорее отношение к пользовательскому (административному) опыту - стабильность фреймворка/приложения при апгрейдах и всё в таком духе. Поэтому я только подсветил проблему - раз уж SQL Server тоже это описывал.
С точки зрения реляционой алгебры, стандарта SQL, консистентности или транзакционности тут вопросов нет, как и универсального решения. Мой поинт в том, чтобы по-простому дать возможность регулировать подобное поведение: ведь не у каждого есть возможность переписать под себя платформу 1С или даже приложение - а пофиксить нестабильность prosupport функциями - это просто.
Хм, я ж наверху сразу написал - я только фичу писал и инцидент расследовал. А уж AI-агент, которым я в это время пользовался, набрал достаточный контекст и сам написал этот пост. Я тут почти ни при чём. - тут же главное, обсудить проблему.
Это вопрос на полноценный разговор. Если совсем просто - то помогает настолько, насколько разработчик знает, что он делает и имеет представление о нюансах предметной области.
С одной стороны, Claude хорош, когда нужно сделать похожий код - см. pg_track_optimiser, где после трех метрик, сделанных под руководством, остальные пять он уже делал сам с минимальными правками. Также, дурацкие баги он часто видит лучше.
С другой стороны, он на голубом глазу часто предлагает резетнуть MemoryContext или использовать что-то из контекста одной транзакции в другой, или использует функцию не так, как это предусмотрено. - по всему видать, что это вопрос вычислительной мощности, он же не может копаться во всем. А контекст его опыта достаточно невелик, чтобы триггерить инсайты, которые заставляют опытного инженера копать здесь а не там.
ну и главное - такие фичи часто до момента разработки не имеют конкретных очертаний - их цель недостаточно ясна и возможность реализации непонятна. Даже корректное название фичи приходит уже после окончания работы, когда начинаешь понимать, что оно по-факту делает, что уж тут говорить про понятный промпт :))).
Проблема с использованием индексов действительно есть. Однако обходить её через generated columns - это больше социальная инженерия, чем решение. Тем более, что для всяких умных генераторов это не выход.
А вот что мог бы сделать серьезный разработчик форка постгреса - так это добавить усиленный CAST клауз запроса при подборе индексов - для общего применения это дорого, но что мешает для специальных кейсов, для аналитиков?
Вообще, для того (в том числе) и придумали разделение ступеней, чтобы иметь возможность использовать разное топливо/двигатели для выведения и маневрирования на орбите и далее. До космоса выгоднее лететь даже не на метане, а на водороде. Метан просто проще в обслуживании - не такой летучий и взрывоопасный. Ну и дешевле, конечно. А наверху логичнее использовать что проще зажечь/погасить/сохранить. Для перегона Земля-Марс может вообще НДМГ выгоднее, если все затраты посчитать - но это уже проект нужно рисовать, чтобы +/- уверенно говорить.
StarShip - действительно рисковый проект, поскольку основывается на совсем новых и не отработанных режимах работы и конструктивных решениях, в отличие от falcon/heavy.
Однако испарение топлива - точно не та проблема, которую стоит так долго мусолить. По крайней мере без математических выкладок, которые для цилиндрического тела достаточно просты. Стоит учитывать, что вакуумная теплоизоляция весьма легка, а тип топлива для космической части РКН может быть и другим - тот же гидразин выглядит понадежнее для задачи многократного запуска.
Так что я бы поставил на стоимость проекта и смещение приоритетов у инвесторов. А так, что Луна, что Марс - технологических проблем при постройке базы везде хватит на два поколения инженеров вперёд.
А если серьёзно, то есть же консервативная часть человечества. Они одержат верх, как это обычно бывает и притормозят развитие технологии на какое-то время, пока наше сознание не привыкнет к изменившейся реальности и мы не научимся жить (или сожительствовать, если это уже форма жизни) по-новому и использовать эту новацию. Вроде ж мир как-то так развивается?
Для параллелизма не важна конкретная таблица - иначе тебе придется анализировать и выискивать ее временные индексы, временные тосты, индексы тостов и пр, которые тоже могут быть в temp_buffers. Перед тем, как Gather запустит первый воркер с временными таблицами внутри, он должен пройтись по temp_buffers и скинуть на диск все dirty-страницы.
Ну так ежели есть что лучше - так и пользовались бы этим. Вроде ж MS Windows не дорого стоит. То же с СУБД. Кто мешает SQL Server использовать? Мне он лично очень нравится - вот только научный проект я на нем не сделаю, а ваять по каждому поводу новый "прототип СУБД" - увольте, мне этого в 0-ых хватило.
Если есть альтернативы open-source - их нужно называть, что зря писать.
То есть, вам нужны чисто испольнители ...
Я бы сказал - те, кто умеет концентироваться на главном. В конце-концов нужно деньги зарабатывать и про домашних не забывать. А то, что у нас есть компромиссы в архитектуре это и так понятно - не видел ни одной системы без компромиссов.
Да, держать на стороне СУБД кэш результатов конкретных запросов - это странная идея. Вот автоматом создавать MATERIALIZED VIEW, чтобы потом их использовать в других запросах - вот это была бы тема!
Здесь самый главный вопрос даже не инвалидация кэша, а насколько часто в БД встречаются абсолютно идентичные запросы, с идентичными константами? Если часто, то может приложению стоит просто самостоятельно запомнить результат?
Ну и да, зависимость от вероятности попасть на коллизию хэшей врядли добавляет DBA спокойствия …
Так вроде ж специально выставляют этот лимит так высоко, чтобы GEQO включился и до 20 джойнов находил разумные комбинации вместо слепого следования синтаксическому порядку, нет?
Ну так вот и хотелось бы конкретики, а не просто слов. Каков главный радиус, как сделаны баки , схемы пайки, чем отличаются гаргроты, силовые кольца, двигатели и их крепления ... . Как минимум одна общая деталь есть - движок 170/171/180/190 - всё та же технология. Пусть и проверенная и надёжная, но та же. То есть не спроектированная нативно под современные материалы/3D печать и прочее.
В целом всё лучше, чем ничего. Как минимум новая версия носителя означает новое КД, новые инвентарные номера в спецархиве, что хорошо, поскольку старое имеет тенденцию теряться.
Но было бы гораздо интереснее и полезнее увидеть сравнение этого Союз-5 с советским предшественником - ну хотя бы крупноузловой анализ, если у автора есть соответствующий материал и компетенции.
Вот только Байтерек непонятно причём здесь. Так-то это был (насколько я помню) проект по заказу Казахстана - создание их собственного носителя для собственного космодрома. Но уже тогда ходили разговоры, что деньги Роскосмос просто проест и предложит что-то готовое с минимальными модификациями. Так что любопытно изучить, что в итоге получилось, чем нынешний союз принципиально отличается от старых. Уж теплозащиту и электронику давно бы следовало обновить.
ИИ агенты эффективно анализируют код уже с полгода. За такой срок для такого широко используемого сервиса как GitHub всего один CVE - это прям успех и показатель качества работы инженеров этой платформы.
Ну, четвертое измерение в логике функций имеет скорее отношение к пользовательскому (административному) опыту - стабильность фреймворка/приложения при апгрейдах и всё в таком духе. Поэтому я только подсветил проблему - раз уж SQL Server тоже это описывал.
С точки зрения реляционой алгебры, стандарта SQL, консистентности или транзакционности тут вопросов нет, как и универсального решения. Мой поинт в том, чтобы по-простому дать возможность регулировать подобное поведение: ведь не у каждого есть возможность переписать под себя платформу 1С или даже приложение - а пофиксить нестабильность prosupport функциями - это просто.
Оно самое. Поэтому и нужна гибкость и тулзы для пост обработки.
Хм, я ж наверху сразу написал - я только фичу писал и инцидент расследовал. А уж AI-агент, которым я в это время пользовался, набрал достаточный контекст и сам написал этот пост. Я тут почти ни при чём. - тут же главное, обсудить проблему.
Это вопрос на полноценный разговор. Если совсем просто - то помогает настолько, насколько разработчик знает, что он делает и имеет представление о нюансах предметной области.
С одной стороны, Claude хорош, когда нужно сделать похожий код - см. pg_track_optimiser, где после трех метрик, сделанных под руководством, остальные пять он уже делал сам с минимальными правками. Также, дурацкие баги он часто видит лучше.
С другой стороны, он на голубом глазу часто предлагает резетнуть MemoryContext или использовать что-то из контекста одной транзакции в другой, или использует функцию не так, как это предусмотрено. - по всему видать, что это вопрос вычислительной мощности, он же не может копаться во всем. А контекст его опыта достаточно невелик, чтобы триггерить инсайты, которые заставляют опытного инженера копать здесь а не там.
ну и главное - такие фичи часто до момента разработки не имеют конкретных очертаний - их цель недостаточно ясна и возможность реализации непонятна. Даже корректное название фичи приходит уже после окончания работы, когда начинаешь понимать, что оно по-факту делает, что уж тут говорить про понятный промпт :))).
Интересно. Если поделиться этим в коммьюнити, то может дело и сдвинется с мертвой точки.
Забавно, спасибо за историю. У нас конечно технологии посовершеннее - тот же presupport, к примеру. Но все равно, опыт любопытный.
Проблема с использованием индексов действительно есть. Однако обходить её через generated columns - это больше социальная инженерия, чем решение. Тем более, что для всяких умных генераторов это не выход.
А вот что мог бы сделать серьезный разработчик форка постгреса - так это добавить усиленный CAST клауз запроса при подборе индексов - для общего применения это дорого, но что мешает для специальных кейсов, для аналитиков?
Вообще, для того (в том числе) и придумали разделение ступеней, чтобы иметь возможность использовать разное топливо/двигатели для выведения и маневрирования на орбите и далее. До космоса выгоднее лететь даже не на метане, а на водороде. Метан просто проще в обслуживании - не такой летучий и взрывоопасный. Ну и дешевле, конечно. А наверху логичнее использовать что проще зажечь/погасить/сохранить. Для перегона Земля-Марс может вообще НДМГ выгоднее, если все затраты посчитать - но это уже проект нужно рисовать, чтобы +/- уверенно говорить.
А космосу не всё ли равно? Жёсткий рентген там тоже здоровья живым существам не добавляет ;)
StarShip - действительно рисковый проект, поскольку основывается на совсем новых и не отработанных режимах работы и конструктивных решениях, в отличие от falcon/heavy.
Однако испарение топлива - точно не та проблема, которую стоит так долго мусолить. По крайней мере без математических выкладок, которые для цилиндрического тела достаточно просты. Стоит учитывать, что вакуумная теплоизоляция весьма легка, а тип топлива для космической части РКН может быть и другим - тот же гидразин выглядит понадежнее для задачи многократного запуска.
Так что я бы поставил на стоимость проекта и смещение приоритетов у инвесторов. А так, что Луна, что Марс - технологических проблем при постройке базы везде хватит на два поколения инженеров вперёд.
Сьюзен Келвин нас спасет.
А если серьёзно, то есть же консервативная часть человечества. Они одержат верх, как это обычно бывает и притормозят развитие технологии на какое-то время, пока наше сознание не привыкнет к изменившейся реальности и мы не научимся жить (или сожительствовать, если это уже форма жизни) по-новому и использовать эту новацию. Вроде ж мир как-то так развивается?
Так ты посмотри в исходники же!
Для параллелизма не важна конкретная таблица - иначе тебе придется анализировать и выискивать ее временные индексы, временные тосты, индексы тостов и пр, которые тоже могут быть в temp_buffers. Перед тем, как Gather запустит первый воркер с временными таблицами внутри, он должен пройтись по temp_buffers и скинуть на диск все dirty-страницы.
Хм, а разница? Полагаю, что и мне придется долго переучиваться, если нужно будет переходить в Оракловые разработчики ;)
Ну так ежели есть что лучше - так и пользовались бы этим. Вроде ж MS Windows не дорого стоит. То же с СУБД. Кто мешает SQL Server использовать? Мне он лично очень нравится - вот только научный проект я на нем не сделаю, а ваять по каждому поводу новый "прототип СУБД" - увольте, мне этого в 0-ых хватило.
Если есть альтернативы open-source - их нужно называть, что зря писать.
Я бы сказал - те, кто умеет концентироваться на главном. В конце-концов нужно деньги зарабатывать и про домашних не забывать. А то, что у нас есть компромиссы в архитектуре это и так понятно - не видел ни одной системы без компромиссов.