Эта история начиналась с процесса валидации FK на очень больших таблицах (1TB+).
Далее я расскажу, какие нетривиальные проблемы встретились по пути, как я их решал, и каким образом можно исследовать довольно сложные проблемы производительности базы данных Postgres.

Добрый день, коллеги! Как известно, компания "Postgres Professional" более не рекомендует использовать секционирование с использованием pg_pathman, а рекомендует использовать вместо него декларативное секционирование. Однако помимо синтаксического сахара и утилитарного кода по поддержке интервального (в стиле Oracle) секционирования, я обнаружил для себя ещё одну проблему в такой миграции (переходе). Надеюсь, коллеги из PGPro доработают декларативное секционирование к моменту окончательного выпиливания pg_pathman.

Не так давно я опубликовал заметку о некотором варианте иерархического запроса, который выполняется очень долго и неограниченно и не потребляет иных ресурсов базы данных кроме CPU.

Возникла довольно естественная идея использовать этот метод для сопоставления CPU интенсивных задач в БД Oracle. Например, если мы встраиваем такую прожорливую CPU-функцию в наш пайплайн исполнения SQL-запроса так, чтобы она выполнилась более миллиарда раз, то получаем возможность сравнить затраты на CPU в разных случаях.

В данном случае мы будем сравнивать по производительности различные функции хеширования в Oracle: ORA_HASH и различные варианты STANDARD_HASH.

перевод второй статьи известного специалиста в области Oracle Фрица Хугланда на тему трассировки postgresql при помощи bpftrace (первую статью я перевёл ранее см. Использование bpftrace для трассировки выполнения запросов в postgres)

В этой статье я приведу демонстрацию использования BPF uprobe/uretprobe для исследования внутреннего мира Postgres вместо usdt-проб.

Эта статья перевод статьи известного специалиста в области Oracle (но про Postgres) — Фрица Хугланда — https://databaseperformance.hashnode.dev/using-bpftrace-for-postgres-query-execution-tracing.

Довольно интересный случай выполнения "Ораклового" запроса, который, надеюсь может навести на некоторые рассуждения о runtime механизмах исполнения.