Ora2pgpro включена в СУБД Postgres Pro Enterprise, чтобы упростить конвертацию кода СУБД Oracle

… достаточно разве чтобы «Hello, World!» написать, предлагаю-таки пойти в бизнес-логику…

Мы, похоже, о разной бизнес логике речь ведём. 99,9% - это и есть чуть сложнее «Hello, World!». Когда уже нужен математический аппарат отличный от реляционной алгебры (астрономия, геология, метеорология, движение жидкостей… ну и всё такое прочее), ясен-красен, никто приклеивать к СУБД специализированные библиотеки не будет (хм… а ведь можно же, некий GIS и некие полнотекстовые поиски таки привязать смогли). Но тут БД опять выплывает в область тупой хранилки большого количества данных.

о разной бизнес логике

я бы к бизнес логике добавил ещё вопросы доступа к данным. Row Level Security, в частности.

Если «бизнес логика на Питоне» ходит в БД под одним и тем же пользователем для всех своих задач - зачем ей вообще какие-то пользователи БД?

Вообще вся эта истерика с выносом из БД всего, что можно и использование БД только в качестве хранилки данных, я так понимаю, растет откуда-то из девопсов, из желания мочь легко и просто поднимать и опускать произвольное количество экземпляров приложения. Монолитность БД в этом вопросе, конечно, будет мешать.

Мы, похоже, о разной бизнес логике речь ведём.

Вот было утверждение, что «для серьезных приложений, бизнес-логика, должна размещаться в одном месте с данными», т.е. ЯП, используемый для реализации этой самой бизнес-логики, каким-то специальным образом приспособлен для обработки данных, данные - это, очевидно, таблицы/роусеты, строки, колонки - вот хочу увидеть пример использования полиморфизма при работе с данными, а не пример перегруженного метода, ну какой-нить расчет страховки на авто в зависимости от типа, стажа владельца, места эксплуатации и т.п. (чтобы было еще по SOLID, все дела)

… я бы к бизнес логике добавил ещё вопросы доступа к данным. Row Level Security, в частности…

Отписал я километровый комментарий, но провалился он куда-то. :) Бывает. Смысл:

Согласен, но на уровне базы долго, муторно, дорого. Никто не заморачивается. Тут на уровне приложения проще. Аутентификация-авторизация… Короче, выдал токен и рули.

… Вот было утверждение, что «для серьезных приложений, бизнес-логика, должна размещаться в одном месте с данными», т.е. ЯП, используемый для реализации этой самой бизнес-логики, каким-то специальным образом приспособлен для обработки данных…

Я как бы не настоящий сварщик и эти ваши Ораклы только на картинках видел… С PostgreSQL до сих пор приходится иногда возиться. Мне кажется, Вы несколько перегибаете. Да, существуют ЯП, которые прилагаются к БД и самым обычным образом приспособлены для обработки данных из этой самой базы данных. Согласен, PL/PgSQL несколько тормозноват, а в триггеры обычный SQL пихается лишним вызовом и тоже не компилируем, но они работают и работают-таки с данными. PL/perl - вопрос отдельный - работа не только с данными, но и с OS (прикольно, да).

… хочу увидеть пример использования полиморфизма при работе с данными, а не пример перегруженного метода, ну какой-нить расчет страховки на авто в зависимости от типа, стажа владельца, места эксплуатации и т.п. (чтобы было еще по SOLID, все дела)

Вот с этого ТЗ ещё бы схему таблиц. Иначе не видно на кой там вообще нужны какие-то полиморфизмы. Для ненастоящего сварщика это что-то типа «Hello, World!», только с пальцами. Вот правда, по описанию даже хранимок не нужно - тупая view с выборкой по владельцу.

… а для PostgreSQL? raise?

Не поверите, с полудня сижу и думаю над этим. Что не так? Поясните, пожалуйста. Водка закончилась, к выводу не пришёл. Как и всё остальное, выкидывает клиенту исключение, обработать тоже можно, в журнал пишется (с нужными приоритетами), сообщения расписаны в документации, понятны, легко кастомизируются. Где подвох?

«Последующий» не в смысле «автоматический», а смысле, что он так или иначе нужен. И он заметен.

А еще insert при update'е суров в смысле разрыхления и обслуживания индексов.

в мелкой компании такой может и прокатит, но в серьезном энтерпрайзе с офисами в разных часовых поясах нужны хотя бы три девятки в плане availability. вариант с окном просто никто и рассматривать не будет. но главная проблема pl/sql - он остановился в развитии 20 лет назад и не оброс комьюнити. в результате абсолютно все там надо велосипедить, окромя пары стандартных ни на какие задачи нет библиотек. ну и как результат никто не хочет погружаться в велосипеды на pl/sql, я вот тоже не хочу, т.к. знаю что за прошедшие 20 лет в жава на кажду. фигню есть шикарная либа или целиком фремворк, с документацией и форумами.

когда-то pl/sql был лучшим инструментом, но язык застыл в процедурных 90х. банально функцию параметром не передать, параллельности ноль, масштабирования считай нет. особенно на больших данных это чувствуется. логика в spark, с его ленивыми вычислениями, параллельностью и масштабированием - просто другой уровень. жава мир в 90х тоже был процедурным и бегал циклами, по циклу погоняя циклом. но теперь крен в сторону функциональщины сильно изменил писанину сложной логики, а вот у pl/sql нифига за 20 лет не изменилось.

Водка закончилась, к выводу не пришёл

нужно было переходить на абсент. ладненько… беды с записью логов примерно следущие:

• их нужно где-то хранить (и это очевидно не plain text, не syslog и не journald)
• по ним нужно уметь эффективно искать, причем ожидается, что если ИС состоит из нескольких компонент, то я логи всех компонент вижу через одно окно и там же могу эти логи коррелировать
• чтобы уметь коррелировать логи из разных систем, мне нужно чтобы у них был примерно один и тот же формат и они должны быть дополнительно обогащены полезной информацией (тут фантазия может быть безгранично, но помимо стандартных время, суровость и сообщение, нужны еще: пользователь, адрес пользователя, бизнес-операция, время выполнения операции, система, модуль)
• еще желательно логи делить на ошибки, диагностику, ИБ и пр.

Из всего этого СУБД и встроенные языки не умеют совсем ничего, в 15-й версии PostgreSQL научился-таки писать в JSON, чтобы можно было не ловить лулзы CR/LR, но дальше оно никак не продвигается.

Чтобы не пришлось еще сильнее травмировать печень: если пользователь ИС плучает привилегии в результате вызова процедуры на ЯП, встроенном в СУБД, то именно эта процедура обязана также правильно, корректно и в требуемом формате залогировать факт получения привилегии (тут уже с траназкциями возникнут грабли).

… нужно было переходить на абсент…

Хм… А ведь прекрасная мысль. Как-то даже не подумал. Но давно уже им не заливался, здоровье не то уже. Увы, старость, по ходу, наступает.

Далее. Почти понял в чём суть такого журналирования, но не понял в чём проблема его осуществить (это чуть расширенный формат syslog). Тупо в лоб - процедурка лога (да хоть по сети кидайте) -> триггер хоть на каждую таблицу с её вызовом / вызов в нужных процедурах… Во что упирается-то?

… в 15-й версии PostgreSQL научился-таки писать в JSON…

В 9.4 (больше 10-ти лет назад). И в xml еще.

… процедура обязана также правильно, корректно и в требуемом формате залогировать факт получения привилегии (тут уже с траназкциями возникнут грабли).

С чего бы? В данном случае процедура будет выполняться в контексте транзакции. Хотя… Хм… При откате транзакции данные всё равно могут оказаться в журнале. Так да, есть риск. А с приклеенной сбоку логикой его нет?

И никто сейчас, в эпоху ITIL/ITSM

«Эпоха ITIL», как ригидных правил, закончилась лет десять, если не 15 назад.

Недостатки ITIL, особенно в части service transition и service operation, широко известны тем, кто эти годы в индустрии провёл, а не в глубокой коме энтерпрайзов. CI/CD, you build it - you run it, shared goals и даже devops, как парадигма появились не потому, что с ITIL всё хорошо было, а потому, что оказалось, что ключевые процессы, как их предполагает делать ITIL, не работают или работают неприемлемо медленно для современных сервисов. А бизнес-потребности сейчас склонены в сторону скорости доставки, а не в сторону надёжности (которую, к слову, всё равно ITIL не обеспечивал).

Менять «на горячую» пакеты и логику на работающей Промышленной среде могут как раз только безхозные любители ORM-ов.

Это примерно как разработчики на коболе для мейнфреймов говорили, что вся эта лажа с распределёнными системами не нужна и только идиоты будут такое использовать, а «Real Programmers Don’t Use Pascal» и тому подобное. По факту оказалось, что быстрая интеграция, сделанная бесхозными любителями ORM-ов и дивапсами, попивающими латте с тыквенным сиропом даёт лучшие бизнес-результаты по сравнению с Настоящими Программистами Промышленных Cред.

Понимание того, как разрабатывается код, постоянно меняется, хотим мы этого, или нет. Люди перестали писать пакетные задания для мейнфреймов, потом сильно сократили написание интерактивных приложений для vt220, потом даже GUI на Oracle Forms писать перестали - вот и код и данные стали разделять и отдельно их деплоить, отдельно масштабировать, отдельно ими управлять. Оказалось, это удобнее, по многим причинам и на фоне удобства и скорости то, что надо по сети в базу из приложения сходить, оказывается незначимой мелочью. Тем более, что 100 Gbps коммутация есть и продолжает дешеветь.

А можете пояснить:

Допустим есть некоторый расчет. Ему требуется сдернуть данные с десятка таблиц и внести изменения в пару-тройку. В один SQL-запрос не влезает.

В чём преимущество иметь возможность легко масштабировать бэкенд перед возможностью написать одну хранимку? Эти сотни бэкенд-коннектов всё равно же пойдут в ту же БД? И как на этих независимых коннектах отслеживать блокировки?

По-моему - единственное, чем должен заниматься бэк в таком случае - каким-либо образом знать надо ли вообще БД дергать, может в расчете ещё ничего не поменялось и можно отдать из собственного кэша готовое.

Эти сотни бэкенд-коннектов всё равно же пойдут в ту же БД?

не пойдут - на бэке есть масса возможностей не ходить в БД:

• возможность иметь глобальный кеш любого разумного размера с привязанными к нему активностями по инвалидации или очень быстрыми проверками актуальности данных
• возможность иметь локальный кеш, привязанный, сеансу, бизнес-компоненте, запросу и чтобы там еще ни было
• возможность читать данные с реплики

Так нет же ещё никаких кэшей. Есть только сырые данные, лежащие в БД.

И вот сотня-другая коннектов к БД пошла за этими данными в БД, чтоб их обсчитать на своей стороне, одновременно каким-то образом отслеживая между собой чтобы «первое» было обязательно перед «вторым», а потом «компот».

Или та же сотня-другая вызывала хранимку. Почему это хуже?

Во что упирается-то?

упирается оно в то, что ЯП есть, а инфраструктуры нет, т.е. недоразвитость инфраструктуры здесь само по себе подразумевает, что вендор СУБД изначально не видит смысла реализовывать эту самую пресловутую бизнес-логику на стороне БД, а попытки реализовать обратное - это из разряда натягивания совы на глобус.

Тохо2, я уже перестал спорить с нашими оппонентами, как я понял, в основном Java-истами, чей язык и технологии (монстроузные сервера приложений, orm, и т.д.) понемного-потихоньку сходит с арены, уступая место другим современным языкам как C#, Kotlin, Scala, Python, Go, Rust.

Для меня очевидно, что они недостаточно глубоко разбираются в СУБД, тем более в Oracle, иначе они не пороли бы той чуши и дичи, которую они осветили выше. Если бы они знали Oracle получше, то им бы было известно, что их любимая Java наряду с PL/SQL имеется внутри Oracle DB, что на ней можно писать и хранимки, и триггеры. Но никто из нормальных разработчиков СУБД это не делает, а используют только в очень редких случаях (у меня такой был - кода надо было выковыривать текст из PDF-документа, который складывался в определенную директорию)

Ну и понятие стоимости и скорости разработки с СУБД, а также кол-ва железа, серверов и не побоюсь этого слова Кластеров :) требуемых для обработки данных на их ORM за пределами СУБД, в их рассуждения не входит.

Ну и как следствие незнания СУБД, orm-щики пытаются натянуть «сову на глобус» - пытаясь применить свой, не всегда адекватный и релевантный опыт трахания с ORM к работе внутри СУБД.

ORM-щикам хорошо бы заучить следующие Правила и приоритеты выбора Языка программирования при создании приложений на Oracle DB:

1. Используйте SQL где можно (имеется ввиду в процедурах PL/SQL)
2. Если SQL не может решить всех поставленных задач, используйте PL/SQL (имеется ввиду логика, структуры, web-стредства и т.д.)
3. Если PL/SQL не может решить всех поставленных задач, используйте Java (обернутые в процедуры PL/SQL)
4. Если Java не может решить всех поставленных задач, используйте C/C++

ПС. там кто-то про «параллельность» писал, мол нет ее в PL/SQL. Так вот «праллельность» в Oracle обеспечивается самой СУБД, обрабатывающией множество заросов от множества сессий. Также есть средства распаралеливания запросов, вставок, обновлений (если к то в курсе, а то, может, ORM-щики этого не знают). И по той же Java, которая внутри Oracle есть настоятельная рекомендация в документации Oracle - не использовать встроенные в Java средства многопоточности (объяснение смотри выше + нехорошо, когда криво написанная программа на Java с многопоточностью завалит весь сервер СУБД). ссылка

перестал спорить с нашими оппонентами

обидно чувствовать себя лохом, уплатившим миллионы за СУБД и при каждом удобном случае ловящим тривиальные ошибки со стороны этой же СУБД, да?

Если бы они знали Oracle получше, то им бы было известно, что их любимая Java наряду с PL/SQL имеется внутри Oracle DB, что на ней можно писать и хранимки, и триггеры

а если книжки читать до конца, то можно было бы прочесть к примеру, что встроенная жава имеет ряд существенных ограничений, сводящих все ее «преимущества» на нет.

у меня такой был - кода надо было выковыривать текст из PDF-документа, который складывался в определенную директорию

прямо чудеса инженерии, не иначе. Попытаюсь объяснить для особо одаренных:

• основная задача СУБД - надежно хранить данные и эффективно их доставать (это не про PostgreSQL если что - там с эффективностью есть некоторые проблемы)
• попытка реализовывать в СУБД бизнес-логику не приводит ни к чему хорошему для конкретного заказчика, зато это крайне выгодно для вендора СУБД: пусть лох платит за то, за что платить изначально не нужно было - стоимость лицензий СУБД не сравнима со стоимостью железа
• обработка в СУБД неродных форматов даных из недоверенных источников ни к чему хорошему не приводит (да-да, «Если Java не может решить всех поставленных задач, используйте C/C++» - идем в cve.mitre.org и смотрим сколько лулзов было в Acrobat Reader: от DoS до RCE, а кто-то это еще от недостатка ума пытается в СУБД встроить)

вот и придумывают всякие pg-пулы и pg-боунсы. И работают они плохо, по отзывам

define «плохо». Баунсер в проде уже лет 8, держит тысячи рпс годами. Единственная проблема (которая от неумения читать документацию вылазит): при работе с несколькими схемами без явного указания схемы в запросе будет забавный результат.

у меня 20+ лет опыта с ораклом и сдается у меня поболее знаний и опыта. до середины двухтысячных оракл был адекватным выбором, но в эпоху многоядерности, когда EE редакцию надо лицензировать по ядрам, а адекватных разработчиков на старичке из 90х не найти, просто глупо затаскивать логику в субд. больше логики - больше ядер, больше EE лицензий. стоимость EE с партишенами, стендбай и датагвард более $60k на x86 ядрышко. ну куда это ? при этом все тоже самое можно достичь на жава где и разработчиков полно и масштабирование не требует миллиарды на лицензии плюс супорт.

java как эентерпрайз тул вне конкуренции, пик популярности scala прошел после того как основные вещи из функциональной парадигмы затащили в жава. C# сгубила ориентация на винду в эпоху восхождения облаков на линуксе и теперь C# core без фреймворков на линуксе выглядит слишком блекло. всякие хадупы, кафки, касандры - все намертво сидит на jvm и соответственно ентерпрайзы, что активно все это используют ориентируются на жава.

по параллельность, бедняки в pl/sql как и 90е выкручиваются запуском dbms_job что бы нечто в параллель запустить. это невозможно сравнивать с современной жава где повсюду теперь асинхронщина и все и вся плодит отдельный тред, в плоть до обхода массивчика. но главный выигрыш деньги, уперлась жава в cpu - добавили cpu и все. в оракле это финишь, добавить cpu это сотни тысяч usd в 3 года с учетом стендбай. в этом нет смысла даже не из-за устаревшего языка, нет смысла по экономическим причинам.

Еще раз скажу: весь мир давно ушёл от хранимок. Весь. И возвращаться к ним категорически не хочет.

Ты хочешь сказать, что ты такой гений, что знаешь лучше 99% программистов и владельцев бизнеса? Все ошибаются, только ты знаешь, как правильно?

Я вот задумался, что мог бы несколько узких мест ускорить в своём проекте, возможно, за счёт хранимок. А потом подумал: а как их версионировать? А как тестировать? А как синхронизировать изменение их кода с изменением кода бэкенда? А как научить всему этому, начиная с синтаксиса процедур, всех коллег? А как я отвечу коллегам, когда они зададут мне все эти вопросы, и кучу других? А стоит ли овчинка выделки?

Вы, конечно, правы, перечисляя проблемы использования хранимых процедур, это все так. Но, к сожалению, альтернативой этому стали всякие монстрообразные надстройки типа того же Hibernate и прочих ORMобразных библиотек, отображающих таблицы на классы. Так вот, работает это все по принципу «select * from all_tables, а дальше руками». Может, конечно, это дело кривых рук программистов, но это примерно то, что я видел сам. Признаюсь, я видел немного.

И вот у меня тогда вопрос — а нафига придумывать все эти оптимизации плана запроса и т.д.?

Кстати, проблема синхронизации кода бекэнда со структурными изменениями в базе все равно остается при любом подходе. Да и вообще проблема синхронизации миграции данных и использующего данные кода решается каждым по-своему, то есть примерно никак.

у меня такой был - кода надо было выковыривать текст из PDF-документа, который складывался в определенную директорию

Прям по живому. Пристрелил бы. Разработчику никогда нельзя давать максимальную свободу, он таких кадавров наворотит, что потом следующие люди будут годами растягивать в разные стороны и разгребать.

С содроганием вспоминаю, как в одном проекте (который надо было срочно чинить) обнаружил отправку почты прямо из Oracle.

Ну, возможно, тут дело в кривых руках и неумении пользоваться. Типа «перешли на постгрес, добавили pgpool, настроили как-то, работает плохо». :) Это не мои жалобы, это жалобы бизнеса, которые до меня доходили. Поэтому, точного определения понятия «плохо» в данном контексте определить не могу.

Ну, то есть, сначала придумываем язык, где тип переменной определяется присваиванием (и заранее неизвестен), а потом прикручиваем к этому полиморфизм в стиле императивных строго типизованых языков... Мндя... На этом что-то мысль останавливается. Не ведают они, что творят :)

Еще раз скажу: весь мир давно ушёл от хранимок. Весь. И возвращаться к ним категорически не хочет…

https://www.google.com/search?q=%D0%BD%D0%B5+%D1%87%D0%B8%D1%82%D0%B0%D0%B9%D1%82%D0%B5+%D0%BF%D0%B5%D1%80%D0%B5%D0%B4+%D0%BE%D0%B1%D0%B5%D0%B4%D0%BE%D0%BC+%D1%81%D0%BE%D0%B2%D0%B5%D1%82%D1%81%D0%BA%D0%B8%D1%85+%D0%B3%D0%B0%D0%B7%D0%B5%D1%82#fpstate=ive&vld=cid:3935de25,vid:LxHdzGDazXg

за слова «весь мир» надо сразу с разворота в рыло бить. Ногой. Петрушки, блин. Ничего тяжелее собственного xyя в руках не державшие.
У нас, в Богоспасаемой, есть куча легаси кода который надо как-то... иметь. И данный тулз - кому-то да поможет. А Бартунов - крутой. В пгпро вообще очень крутая команда.

а в чем проблема с самим фактом отправки именно из оракла? я тебе секрет открою - внутри ынтырпрайза это сплошь и рядом. Работает уж всяко не хуже, чем говно на каком нить джиквери+реакт.
Оракел идет нахер не потому, что технологически слаб, а потому что пидopы. в плохом смысле слова.
Ну и вообще - сравнивать оракел, в который влили оxyлиард бабла и постгрес, который пилить более-менее начали всего как год-два... ну такое...
С прямой обязанностью - ворочить стотерабайтными базами - вполне себе справляется. Остальное приложится.

Допустим есть некоторый расчет. Ему требуется сдернуть данные с десятка таблиц и внести изменения в пару-тройку. В один SQL-запрос не влезает.

Допустим, есть бесконечное число различных сценариев, встречающихся в 0.01% или меньшей доле реальных ситуаций.

Например, допустим, надо сдернуть данные из mapreduce с или даже без SQL фронтенда, нетривиально их обработать и положить в базу. Или, допустим, есть десяток баз, а не десяток таблиц. Или, допустим, таблицы не помещаются в одну ноду, и хочется шардинг сделать так, чтобы шард каталог не был узким местом.

Допустить можно что угодно.

А на деле оказывается, что в нужно данные по ключу взять или положить. И что логика шардирования может быть в клиенте или в сайдкаре к нему. И что запросы в сервис идемпотентны, потому, что API надизайнен был правильно. А все эти допущения актуальны только на уровне представления к базе и поэтому можно перед ней поставить REST или другой RPC сервис, а с базой напрямую не общаться.

Если вам от РСУБД только и надо что

нужно данные по ключу взять или положить

то понятно, что вам из этих букв и нужно только последние две.

Крайне маловероятно, что для «по ключу взять или положить» кому-то в голову придёт затаскивать в проект Oracle или Postgres.

логика шардирования может быть в клиенте

прям серпом по

Ладно, спасибо за ответ. Познавательно.

работает это все по принципу «select * from all_tables, а дальше руками»

кто-то слишком предвзято относится к одной технологии и слишком восторженно к другой, а скорее всего, этот кто-то не имеет какого-либо релевантного опыта ни с тем, ни с другим (ну вот я не могу себе представить в какой вселенной «бизнес» должны беспокоить аспекты использования pgpool - это даже не лежит в области ответственности IT-директора).

Вот если-таки вдумчиво почитать документацию по PostgreSQL, то можно невооруженном взглядом заметить, что PostgreSQL никак не ограничивает потребление ресурсов серверными процессами, точнее даже так: есть geqo_threshold, который как-то пытается влиять на планировщик и есть work_mem, который заставляет выполнять сортировку и hash join на диске, а больше в этой замечательной СУБД нет ничего, что в свою очередь приводит к довольно «забавным» результатам, а именно (кто хочет, может завести CVE про remote DoS):

1. БД можно просто взять и положить одним SQL-запросом, например:

create table t1 (c1 integer primary key, c2 varchar(255));
create table t2 (c1 integer primary key, c2 varchar(255));
create table t3 (c1 integer primary key, c2 varchar(255));
create table t4 (c1 integer primary key, c2 varchar(255));
create table t5 (c1 integer primary key, c2 varchar(255));
create table t6 (c1 integer primary key, c2 varchar(255));
create table t7 (c1 integer primary key, c2 varchar(255));
create table t8 (c1 integer primary key, c2 varchar(255));
create table t9 (c1 integer primary key, c2 varchar(255));
create table t10 (c1 integer primary key, c2 varchar(255));
create table t11 (c1 integer primary key, c2 varchar(255));
create table t12 (c1 integer primary key, c2 varchar(255));
create table t13 (c1 integer primary key, c2 varchar(255));
create table t14 (c1 integer primary key, c2 varchar(255));
create table t15 (c1 integer primary key, c2 varchar(255));
create table t16 (c1 integer primary key, c2 varchar(255));
create table t17 (c1 integer primary key, c2 varchar(255));
create table t18 (c1 integer primary key, c2 varchar(255));
create table t19 (c1 integer primary key, c2 varchar(255));
create table t20 (c1 integer primary key, c2 varchar(255));

set geqo = off;

select t1.c1
from t1, t2, t3, t4, t5, t6, t7, t8, t9, t10,
     t11, t12, t13, t14, t15, t16, t17, t18,
     t19, t20, t1 tt
where t20.c2 = '1' and t1.c1 = t2.c1
  and t1.c1 = t3.c1 and t1.c1 = t4.c1
  and t1.c1 = t5.c1 and t1.c1 = t6.c1
  and t1.c1 = t7.c1 and t1.c1 = t8.c1
  and t1.c1 = t9.c1 and t1.c1 = t10.c1
  and t1.c1 = t11.c1 and t1.c1 = t12.c1
  and t1.c1 = t13.c1 and t1.c1 = t14.c1
  and t1.c1 = t15.c1 and t1.c1 = t16.c1
  and t1.c1 = t17.c1 and t1.c1 = t18.c1
  and t1.c1 = t19.c1 and t1.c1 = t20.c1
  and tt.c1 = t2.c1;

2. БД также легко укладывается на лопатки простейшим PL/pgSQL:

do
$$
    declare
        pool text[] = array []::text[];
    begin
        for counter in 1..1000000000
            loop
                pool = array_append(pool, 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx');
            end loop;
    end;
$$;

Из этого вполне легко можно сделать вывод, что PostgreSQL просто-напросто неприспособлен для реализации нетленок на PL/pgSQL.

ERROR: invalid memory alloc request size 1085997440

Если это лопатки - всем бы такие.

Если это лопатки - всем бы такие.

13-й сжирает все что можно и пристреливается OOM, после чего БД падает в crash recovery, даже если в какой-то версии что-то да починили, захардкоженное ограничение в 1Gb в век терабайтов - так себе история.

Вы немного не о том. Уложить можно что угодно, это не сложно. Я писал об эффективности (а, точнее, о неэффективности) известных мне надстроек на СУБД для разработки бизнес-логики. Вместо оптимизации плана запроса мы имеем попытку вынуть все данные и отобрать нужные уже программно выше уровня БД. Цена этой «гибкости» — излишний сетевой траффик, нагрузка на БД и бесполезная трата процессрного ресурса. Если Вам известен хоть один эффективный ORM, то поделитесь знанием, мне тоже интересно. Глубоко эту тему я не копал, не моя область, но чем только заниматься не приходилось.

я согласен, тяжелые запросы на орм, создают сложности, но и мода на орм для чего-то кроме crud ушла в прошлое. аналитические системы строятся на spark фрейворке, а у олтп работы с рсубд заметно поубавилось. здоровый пласт ушел на очереди данных, всякие kafka, rabiitmq и логика вокруг очереди (тут тоже зачастую spark), всякие индексы аля elastic/solr, классическая база это уже нечто на последнем рубеже, где тяжелые запросы модно теперь строить без орм. просто jdbcTemplate из спринга или jooq (продвинутый конструктор запросов).

А бизнес-потребности сейчас склонены в сторону скорости доставки, а не в сторону надёжности

Вчера на Озоне видел, видимо, пример такой склонности. https://imageup.ru/img73/4399889/o.jpg

Красота.
Особенно «Табличка для бани „Банька Владимира“» хорошо получилось.

То ли у них ClickHouse разъехался, то ли какие микросервисы поссорились между собой.

---

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

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

Простите. Больная тема.

Такая штука используется потому, что когда-то были сеть нетварь со своими финтифлюшками, LU.6 имени ИБМ со своими финтифлюшками и какие-то ещё. Вот чтобы описать куда ходить, где стоит гейт ораклячий для преобразования этого самого Oracle*Netкакойтотамверсии и использовали такой синтаксис. Лисенер тоже был нужен для получения клиентом инфы куда идти. Ну сидит клиент на паскакале в нетвари под какой-то версией МС-ДОС, а ему надо на манфрейм ИБМ с его LU.6 через кусок сети TCP/IP. Вот у лисенна в listener.ora и в tnsnames.ora на клиенте такое и описывалось.

Сколько оно стоит?