hck1есть факты и они упрямы. ни биржи, ни банки никто, где большой поток OLTP транзакций постгрес не ставят.
Ставят. Вы бы погуглили-то по соответствующим ключевым словам перед тем как писать.

hck1мусор в датафайлах гарантированная смерть перфоменса OLTP.
Потому что Вы так говорите?

hck1поэтому платят ораклу, который был изначально сделан с правильным UNDO, с правильной версионностью блока, а не строки. Я вот подозреваю (хотя мне лично Oracle совсем не интересен), что им платят сегодня в основном потому, что платили вчера (vendor lock-in).
И технические характеристики тут роли не играют.

hck1все там так https://www.postgresql.org/docs/10/static/ddl-partitioning.html
все те же тригера, отсутствие primary & foreign keys. а на дворе бигдата и 21 век ...
Да, на дворе 21 век, а Oracle всё всем впаривает недо-ACID RDBMS как чудо техники.
Ещё одна победа маркетинга, что тут скажешь.

hck1если бы ставили ты бы уел именами, а так молчишь, понимая что гугл в верхних строчка лишь миграцию убера с посгрес показывает.
Не надо мне говорить, что я бы сделал, и я не скажу тебе, куда бы ты пошёл, ok?
И искать за тебя я тоже не собираюсь. Подожди, может ещё кто-нибудь тебе "подаст", раз сам не можешь.

hck1потому, что пг хранит мусор прямо в датафайлах и заставляет все конкрурирущие транзакции читать гигабайты мусора.Он специально туда добавляет "гигабайты мусора", что ли? ;)
А это на самом деле компромисс --- здесь наилучшего решения просто нет (что неоднократно обсуждалось в сообществе, ну уж Oracle-то "знает, как надо").

hck1плюс не так давно послушал с какими проблемами столкнулись товарищи запуская 1с.
Даже слушать не хочется, если честно (разве что 1C если в последнее время полностью сменила свой принцип работы с PostgreSQL (да и хранения данных вообще, если уж на то пошло), т.к. раньше это был тихий ужас).

hck1у пг все очень плохо с потрохами.
Нет.

hck1нормальному современному продукту вендор лок не помеха. опен соурс хадуп успешно выдавливает абсолютно тот же оракл из ниши dwh и никакие вендор локи не мешает. ранее линукс, апач скушали комерческие юниксы и вебсервера и снова вендор лок не помешал.
DWH это именно что ниша, не более того. Т.е. это всегда производные, вторичные данные (хотя и важные для бизнеса). Я лично видел смену трёх DWH-платформ у клиента за 5 лет, и что?

hck1у оракла все хорошо с ACID, как бы ты не злился.
Это просто факт, так что мне злиться незачем. ;)
http://www.bailis.org/blog/when-is-acid-acid-rarely/ , например.

hck1оракл бы не стоял на вершине TPC-C и каждом банке. TPC-C фигачит миллионы update и delete и оракловому UNDO это не создает никаких проблем
ROFL! На "вершине" он там стоит исключительно из-за отсутствия других участников (этот сильно устаревший benchmark сейчас уже никому не интересен, но другие эта ваша недо-ACID СУБД просто не может , вот и "соревнуются", болезные).
А в современных его как-то не видно.

hck1надо. ведь я прав, а ты кроме глупого надувания щечек аргументов привести не можешь. нет тяжелых олпт под посгресом. и в бнчмарках от силы 4-6 ядер, дальше вакум посгресу не дает масштабироваться.

Ты лев. Иди погугли, помогает... тем, кто умеет читать.

hck1есть. берешь TPC-C и смотришь кто там на вершине. этот тест заточен под блокировочник, но оракл со своим UNDO умудряется и тут побить всех.
Ага, при отсутствии других участников. ;)

hck1блокировочники не пишут в UNDO, не лезут в UNDO за прошлой версией, тупые транзакции коротки примитивны и не создают им проблем с блокировками, но все равно оракл обгоняет. потому что UNDO реально наилучшее решение и это не теория, это top 10 tpc-c.
Кого обгоняет? Задолбал ты уже со своим TPC-C, если честно.
Кстати, если уж заниматься раскопками: https://www.opennet.ru/openforum/vsluhforumID3/37878.html

hck1факт в том что у тебя нет базового ИТ образования, как и у того блогера."Тот блогер" computer scientist, детка. Насчёт меня ты тоже не угадал.
И демагогические приёмы, вроде перехода на личности оппонентов, тебе, похоже, тоже не очень удаются.

hck1ACID и IL serializable вещи параллельные.Ты хоть бы открыл определение ACID в ISO SQL, недоучка.

hck1не иметь лога транзакций и соответственно не иметь ACID. Лог транзакций --- не единственное средство обеспечения durability (но, насколько мне известно, наилучшее).

hck1ты бы почитал какой-нибудь вводный крус в рдбмс, там это разжевывают на первых страницах. Начни с себя. Ты что, путаешь Durability с Isolation?

hck1p.s. оракл как и постгрес не имеет range блокировок, потому есть сценарии, где ACID транзакции не выстраиваются в абсолютно точно порядке в каком пришли. но у пг точно та же "беда". и эта "беда" в оракле никого не трогает вот уже 30+ лет, при том что процессит оракл без малого половину фин транзакций мира.
Oracle --- да, не имеет. В отличие от... а остальное вообще набор слов. Ты бы почитал про SSI, прежде чем чушь нести.

hck1оракл был там на вершине и 10 лет назад, когда участников было полно. и 5 лет назад и 15. дело не в устаревшести, а в том что тот же посгрес уже на 10% от той нагрузки дохнет и занимается лишь вакумом. вакум не дает нормально масштабироваться, а оракл с UNDO запросто миллионы tpc в секунду глотает.
Докажи. Всё это звучит как заевшая пластинка.

hck1Ты смешон, acid не требует сериализованности транзакций. У тебя пробел в базовом образовании ...
Требует сериализуемости. Не осилил даже стандарт SQL, недоучка?
Вообще, чтобы сморозить такую чушь, нужно об ACID не знать практически ничего.
Скажи мне, это характерный для "специалистов" по Oracle уровень "базового образования"? ;)