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

Решил зафиксировать решение, так как по-прежнему на собесе это могут спросить. IRL, за всё время работы с Oracle, дубли приходилось удалять только в одном случае - когда я их до этого по ошибке сделал)).

Периодически при ELT приходится изменять алгоритмы сбора таблиц в базе. Хорошо, если эта таблица сама по себе, и больше нигде не используется, или эти изменения не могут никак повлиять на существующие пайплайны или другие объекты. Но не всегда это так, увы, и приходится смотреть зависимости.

Коллектив авторов аж из 6 человек сочинил это поделие объёмом 227 страниц. И выложил на litres. За 790 рублей(!).

Изредка какие-то процессорные группы сохраняю как template и выгружаю в виде xml "на память". И периодически забываю, как это делается. Могу наоборот, по ошибке вместо сохранения шаблона уже существующие выгрузить. Записал инструкцию, чтобы больше такого не повторилось.

Устанавливал с помощью PIP, так что нужен уже установленный python и прописанные в окружении системные переменные.

На память.

Недавно столкнулся с таким багом PostgreSQL. Жил себе да поживал в продакшне джоб Pentaho, в котором в том числе вызывается всякий pl/pgsql. И внезапно начал валиться с постгресовской ошибкой "too many range table entries". Версия PostgreSQL 13.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit.

Зачем это может понадобиться? Например, в приложении пользователь вводит список значений в одну строку, разделитель - запятая. Для известной таблички scott.emp ввод может выглядеть так: SMITH,ALLEN,WARD.

Воспользуемся известной схемой SCOTT, для примера преобразуем таблицу emp. А именно, создадим новую табличку, в которой добавим несколько статей доходов работникам по некой логике. Это тривиально, по коду всё видно:

Используем известную схему SCOTT, таблицу EMP.