Читать можно. А разобраться самому все же полезней.

Навеска MERGE на уже имеющийся INSERT ... ON CONFLICT ... с одной стороны, добавляла только WHEN NOT MATCHED BY SOURCE, а с другой стороны сохраняла всю кривизну UPSERT, когда WHEN MATCHED отрабатывает уже после попытки INSERT и обнаружении дублирующего ключа. Утрирую немного. Если более честно, между слияемыми наборами данных осуществляется исключительно LOOP JOIN, а варианты HASH и MERE JOIN архитектурно невозможны.

Если посмотреть на реализацию MERGE, например, в MS SQL то можно заметить, что там сначала наборы объединяются с явным предпочтением MERGE JOIN по кластерному индексу целевой таблицы, а потом уже, по результатам FULL JOIN начинают отрабатывать WHEN MATCHED и WHEN NOT MATCHED.

Ригс, впрочем, сам признавал кривизну своего решения. Но аргументировал тем, что лучше его кривой вариант, который потом все равно потребуется рефакторить, чем вообще никакой. Так как я использую MERGE, в основном, в DW задачах, то для меня лично от реализации Ригса толку было бы очень мало. Возможно, кому то такой медленный MERGE и пригодился. Но шансы на его рефакторинг тогда стали бы явно ниже, чем на реализацию быстрого MERGE.

Есть INSERT ... ON CONFLICT ... . Но до MERGE он явно не дотягивает.


А вот с этим намного лучше, благодаря конструкции RETURNING в INSERT. То есть, можно вставлять в несколько разных таблиц разные данные, но базирующиеся на результате вставки в предыдущую таблицу.

Если когда-нибудь Вам доведется решать DW задачи, тогда осознаете пользу массивов. Обычный анализ нескольких миллионов временных серий (timeseries) ускоряется в разы при использовании массивов, благодаря радикальному сокращению размеров индексов и затрат на их модификацию. Ну и интерфейс с тем же R через массивы намного эффективней, чем через SPI.
Можно, конечно, хранить числовые вектора и матрицы в JSON, но эффективность такого решения точно будет под большим вопросом.

Некорректное сравнение. Правильно так. Cледует из того, что стоимость владения Kia Rio почти в два раза меньше, чем Skoda Rapid то, что вторая в два раза лучше первой?
Оутсорсная поддержка Open Source нередко обходится дешевле, чем поддержка закрытого программного продукта просто из-за рыночного ценообразования в первом случае и монопольного - во втором.


Хороший, понятие относительное и субъективное и к выбору СУБД имеет очень слабое отношение. "Что русскому хорошо то немцу смерть" (с)
Вы, возможно очень удивитесь, но есть задачи, которые PostgreSQL решает лучше Oracle.


Я читал об успешном использовании PostgreSQL на IBM LinuxOne III с полутора сотнями ядер. Впрочем БД там была невелика - меньше петабайта. Для БД свыше петабайта лучше смотреть все же в сторону Citus.
Есть подозрение, что столь скромные требования устроят в 99.9% случаев.

А у меня подозрение в обратном. Разница знаете в чем? В том что Ваши подозрения диванного эксперта не обоснованы ничем. А мои обоснованы .


Я так понимаю, что если бы Вы действительно хотели это узнать, то воспользовались бы для этого гуглом. Поэтому не вижу смысла отвечать )))


Не стоит вытаскивать на божий свет историю пятилетней давности. Uber там тоже накосячил не мало, много копий тогда сломалось. Факт в том, что выводы из этого были сделаны еще в 9-ой версии PostgreSQL, а сейчас имеем 13-ую.
Успешных переходов было очень много. Просто никто при успехе холивар по всему интернету не устраиват.

Я ведь специально выбрал два автомобиля одного класса и примерно одинаковой цены. И такая разница обусловленна исключительно ценовой политикой на запчасти и сервисное оборудование двух разных производителей. )))


Вообще то, в равной степени можно утверждать и совершенно обратное. И оба утверждения будут ничем не обоснованы. Обе обсуждаемые СУБД активно развиваются.


Я бы еще мог понять Ваш намек, если бы я явно указал, что это успешное использование было в РФ. Но так как в РФ я не знаю ни одного такого случая, а предлагает такую конфигурацию Fujitsu, то в то, что она ориентирована только на "забабахать" почему-то верится с трудом. )))

Я уважаю Ваше право на субъективное мнение. Но от этого оно не перестает быть всего лишь Вашим IMHO. Я, например, считаю наоборот. Для меня 92-ой бензин, шестиступка и 123 лошади Kia важнее, чем Rapid с 95-ым, пятиступкой и 90 лошадями. Но я избежал субъективных оценок, сравнивая технические характеристики. А Вы - нет.


Не знаю, как в мире, но в РФ это очень близко к истине. Kia Rio успешно держится в TOP-3 который год, а Rapid и в TOP-20 не попадал ни разу.


Да ладно )))

Я уже и так пречитывал и этак. Но все равно получается, что следует оценивать вероятность только того, что добавиться могут только задачи, которые PostgreSQL решает хуже, а Oracle их уже решает, да еще и лучше станет решать исходную задачу.
А оценивать вероятность обратного, что при выборе Oracle появятся задачи, которые он решает хуже, а PostgreSQL к тому времени станет решать исходную задачу лучше - как бы не надо, так как этого не бывает )))



Позвольте с Вами не согласиться. Никто не выбирает СУБД подбрасывая монетку. Поэтому положительный результат какого-либо проекта с СУБД говорит еще и о том, что критерии выбора СУБД оказались верными. Да, мы не знаем этих критериев. Но они наверняка были и что-то привело в данном случае к выбору PostgreSQL, а не Oracle. А опыт рынка, особенно в консервативной области мэйнфреймов, показывает, что такие решения обладают свойством повторяться.



Или наоборот втрое медленней на более мощном железе. )))
Или я опять пропустил где-то слово "вероятность"? )))

Вы сами не замечаете свою предвзятость? А с предвзятостью можно только потешить свое ЧСВ, а вот доказать ничего невозможно )))