kdv, не могли бы вы оказать любезность и указать точно, что именно из процитированного вами вы посчитали х-ней.

Касательно ваших замечаний:
а) диссертация Рида относится к 1978 году,

а "теоретическая статься" Бернштейна и Гудмана, которую, вероятно, вы подразумевали, и которая ссылается на Рида как на "первооткрывателя", относится к 1981му


в) в 1984 году Interbase еще как торговый марки не существовало. Она случилась примерно годом позже.
Но существовал Джим Старки, который уже успел написать свою реализацию для DEC, обидеться и уйти с нажитым.
Сейчас википедии пишут, что писал он её для DEC Rdb. И, похоже, что это не совсем так, или совсем не так.
Скорее он работал над неким pet-проектом в расчете на последующее промышленное применение в Rdb,
и уход из Dec, почти наверно, был связан именно с отказом приема его реализации в Rdb как стандартного способа обеспечения
concurrency, а не с тем, что там он все сделал и больше ему делать было нечего.

Да, и еще, у Джима не было физической возможности сказать, что он знать никогда не знал Бернштейна и в глаза его не видел,
просто потому, что они несколько лет работали вместе.
Но он смог сказать, что всё, что придумал, он придумал сам, не читая ничьих статей.

ОКТОГЕН,

золотой пули одной, годной на вообще все уже мыслимые или еще вперед не придуманные ситуации быть не может.
Почему вы, кстати, не вспоминаете про MySql, например?
После появления MariaDb он вполне встал в ряд архитектурно современных конструкций, годных для практического использования.
Общая стоимость владения у него, вероятно, ниже, чем у Postgress и развивается он, может быть и не столь бурно, как Postgress,
но вполне отчетливо.

Что касается взгляда из очень высокого высока, то Oracle и Postgress - это просто одно и то же,
поскольку в главных общих чертах совпадает их архитектура, определяемая тем, что в обоих случаях речь идет
о disk-oriented, row-stored системах с блочным хранением информации и стоимостным оптимизатором sql-запросов.
И исторически первым полностью архитектурно сформированным образцом системы такого сорта был именно Dec Rdb (теперь - Oracle Rdb)

А то количество чертей, которое сидит в деталях, с дальнего расстояния не видно.
Разглядывание их вблизи позволяет точнее разнести типичные сценарии использования.

Так, Oracle, например, очевидно, точно и мастерски (среди систем с версионным управлением конкурентным доступом)
заточен в первую очередь именно под "типичную" OLTP-нагрузку.
Это непосредственно и прямо следует из того, что его схема не просто хорошо согласована с блочным способом хранения
информации, но и из того, что между писателем и читателем приоритет явно отдан писателю.
Такой ход в голову не сможет придти, если ты не думаешь сосредоточенно о том, какие главные характеристики производительности ты обязан сохранить, не взирая на приляпывание в свою систему версионности.

Кобанчег,

я именно за темой dml error logging не слежу, по сути, но на память помню, что ее исходная функциональность была достаточно ограниченной, чтобы вообще принимать за интересную для боевой в случае OLTP ситуации.
Пропуск dup_val_on_index автоматически обесценивает "фичу" для случая OLTP-нагрузки, а отказ отслеживать direct path load по сути обесценивает ее и для прочих сценариев, оставляя очень узкое окно возможностей.
Это все лишь подчеркивает, что когда ты стремишься объять необъятное - неизвестно заранее, смешным ты окажешься
или не очень.

На другой стороне именно той же самой медали находятся технологии, которые они непрерывно совершенствуют в своих реализациях Exadata.
То, что происходит там, натурально вышибает мой мозг как "наблюдающего".
Сейчас они позиционируют себя примерно так: "если у вас достаточно денег, то за ваши деньги мы сможем обеспечить
приемлемую для вас работоспособность на любых доступных для вас на сегодняшний день объемах данных".
Когда просто смотришь первым взглядом на современную Exadata, то автоматически начинаешь в это верить
от изумления, вызванного наблюденным. Но второй взгляд все-таки возрождает движение червячков: да, нет сомнения в том,
что 128-мегабайтное чтение на два порядка лучше 1-мегабайтного на фуллскане,
а кластеризация таблицы по атрибутам дает впечатление, что ты навсегда избавлен от проблем с переизбытком индексов,
трехкратная буферизация записи производит впечатление, что тебе вообще вручили волшебную палочку на запись...
Но все это поверх тщательно охраняемой исходной disk-oriented, row-stored блочной архитектуры.
Путем манипулирования железом можно довольно широко раздвигать границы применимости системы и натягивать ее на новые бизнес-кейсы, но, у хорошего специализированного решения всегда остается возможность превзойти все твои попытки показаться миру универсалом.
Как-то так я думаю.

Никанор Кузьмич,

Мне нужно, чтобы для OLTP-случая dml error logging работал точно так же, как Save Exception,
иначе он не интересен для такого случая, даже если объем вставки не превышает возможностей обработки ошибок в forall.
А для загрузки в stage-таблицу мне было бы интересно логирование загрузки в режиме direct path/

Когда нет ни того, ни другого, указания на желтый цвет штанов становятся бессмысленными для извлечения практической пользы.

Это очень хорошо, когда update не нужен.
А по поводу тормозной херни - ну, что-то должно быть тормозной херней, в конце концов.
Это же вам не биткоин какой-нибудь в первичной реализации.


Я никакого не хочу, мне не надо. Весь "хайлоад" где-то в яве непрерывно сейчас живет.
А я без этой зверушки прекрасно обхожусь.