В геометрии визуально многое наглядно. Если вы геометр землемер, то этого достаточно. Если ученый - то все равно придется формально доказывать ваши построения, и тогда выяснится, что "всё не так однозначно".
Оверхеда нет лишь в том случае, если родной SQL engine заменяется новым, опираясь на storage API, включая переписанный оптимизатор. Можно ли назвать это постгресом? Вопрос риторический. Далее в исходнике встречается CREATE CLUSTERED INDEX или CREATE PARTITION FUNCTION и на этом эксперимент завершается костылями ввиду ограничений storage.
Тот же конвертер, только динамический, но требующий, по сути, переписать SQL engine и системные хранимые процедуры с трансляцией в язык целевой СУБД. Дальше все это заткнется на ограничениях storage engine. К тормозам самого постгреса добавляем еще и оверхед слоя трансляции "на лету".
Не нашел ни слова о том, что компилятор у Go неоптимизирующий, в отличие от С/С++, Rust и даже C#. Борьба с GC - первый признак того, что инструмент не вполне адекватен задаче.
Много слов о процессе (версионность промпта-псевдокода тоже опущена), но мало о цели. Судя по кратким фразам, функциональная сложность на уровне "записная книжка". Это неплохо, просто надо помнить, что такие примеры приложений создавались без написания даже одной строчки кода и 30 лет назад при помощи RAD типа Delphi.
Писать относительно много кода (сотни строк в день) требуется только на этапе "нулевого цикла". Очень быстро все приходит к норме "несколько десятков строк в день". Кодирование всегда занимало в среднем 10-20% времени, да и программирование - не кодирование.
Вы снова отклонились от темы. Видимо, использовать для тех же целей постгрес не будет считаться "пьяным угаром". И, внезапно, keyvalue на SQL Server быстрее Redis, можете проверить на досуге.
Распределенные БД имеют разнообразную топологию в зависимости от требований к системе, и при любом раскладе они основаны на репликациях или, не к ночи буде упомянутой N-фазной фиксации. Не нужно делать обобщений и, тем более, ссылаться на "хайлоад", если вы переходите на менее производительные платформы. Ладно, вы пошли на второй круг, так что удачи.
В геометрии визуально многое наглядно. Если вы
геометрземлемер, то этого достаточно. Если ученый - то все равно придется формально доказывать ваши построения, и тогда выяснится, что "всё не так однозначно"."Господь, жги!" (ц) :)
Можно начать отсюда: SQL Server as key-value store versus Redis
См. комментарий выше. По поводу "исполняются с той же скоростью" смешно пошутили.
Оверхеда нет лишь в том случае, если родной SQL engine заменяется новым, опираясь на storage API, включая переписанный оптимизатор. Можно ли назвать это постгресом? Вопрос риторический. Далее в исходнике встречается CREATE CLUSTERED INDEX или CREATE PARTITION FUNCTION и на этом эксперимент завершается костылями ввиду ограничений storage.
Тот же конвертер, только динамический, но требующий, по сути, переписать SQL engine и системные хранимые процедуры с трансляцией в язык целевой СУБД. Дальше все это заткнется на ограничениях storage engine. К тормозам самого постгреса добавляем еще и оверхед слоя трансляции "на лету".
В Париже из трех бед две ушли: каршеринг умер на начальной стадии, а самокаты убрали после многочисленных выступлений граждан.
Потому что NoSQL - это ребрендинг СУБД и моделей данных, существовавших до SQL
Не нашел ни слова о том, что компилятор у Go неоптимизирующий, в отличие от С/С++, Rust и даже C#. Борьба с GC - первый признак того, что инструмент не вполне адекватен задаче.
Если и тесты генерируют другие "промпты", то есть более дешевая альтернатива - кропить сервера святой водой.
В каждой шутке есть доля шутки :)
Много слов о процессе (версионность промпта-псевдокода тоже опущена), но мало о цели. Судя по кратким фразам, функциональная сложность на уровне "записная книжка". Это неплохо, просто надо помнить, что такие примеры приложений создавались без написания даже одной строчки кода и 30 лет назад при помощи RAD типа Delphi.
Писать относительно много кода (сотни строк в день) требуется только на этапе "нулевого цикла". Очень быстро все приходит к норме "несколько десятков строк в день". Кодирование всегда занимало в среднем 10-20% времени, да и программирование - не кодирование.
Скорее, претензия к компетентности авторов в теме сиквела. Открываем результат "призера" о3 и видим
то же яйцо, но сбокуту же проблему и ошибку.Открываю первый же запрос o3-mini‑high:
трудносопровождаемый copy-paste код, требующий примерно столько же комментариев, сколько и сам запрос
ошибка при выводе/формировании результата (для величин < 8.005)
Не финтехом единым. ERP или её подобие есть на любом предприятии. Это core system.
Просто вспомните о том, что когда бизнес меняет приложения, то данные мигрируют в новую систему. Потому что данные - основной актив.
Вы снова отклонились от темы. Видимо, использовать для тех же целей постгрес не будет считаться "пьяным угаром". И, внезапно, keyvalue на SQL Server быстрее Redis, можете проверить на досуге.
Распределенные БД имеют разнообразную топологию в зависимости от требований к системе, и при любом раскладе они основаны на репликациях или, не к ночи буде упомянутой N-фазной фиксации. Не нужно делать обобщений и, тем более, ссылаться на "хайлоад", если вы переходите на менее производительные платформы. Ладно, вы пошли на второй круг, так что удачи.