Недавно у меня возникла задача по разбиению мульти-терабайтной таблицы на равные диапазоны по числовому полю id. Причём данные распределены по id крайне неравномерно, где-то есть большие "лакуны", где-то непоследовательная генерация и т.д., и т.п. Конечно, можно применить честное решение в лоб — использовать функцию NTILE, но я довольно быстро осознал, что это приведёт к многочасовому запросу с большой вероятностью упасть из-за недостатка TEMP. Но, к счастью, зачастую в таких задачах, как и в моём случае, идеальное разделение на диапазоны не требуется, достаточно более-менее приличного.

Я решил провернуть небольшой трюк для получения приблизительного разделения. Давайте посмотрим, что у меня получилось на модельном примере.

Недавно я изучал детали реализации взаимодействия клиента PostgreSQL с базой данных и был удивлён, насколько легко просматривать трафик PostgreSQL с помощью wireshark. Когда я поделился своим удивлением в социальной сети, меня попросили привести пример того, как это сделать.

Добрый день, коллеги!

Сегодня я хочу поделиться некоторыми проблемами (и решениями) при создании большого количества индексов и ограничений целостности (констрейнтов) одновременно.

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

При развёртывании новой крупной базы данных с «нуля» (например путём миграции), возникает необходимость построить также большое количество индексов в весьма ограниченное тех. окно. Как известно, процесс построения индекса это не только ценный мех IO, но и довольно большое количество CPU при достаточно производительной дисковой подсистеме. Чем больше ядер вы сможете задействовать — тем быстрее пойдёт процесс (в общем случае утверждение, конечно, спорное, но в моём случае обоснованное и проверенное).

На пути «параллелизации» всего и вся возникают разнообразные проблемы, про 3 такие проблемы я и хочу рассказать сегодня.

Добрый день, коллеги!

Недавно мы столкнулись со следующей проблемой при тестировании СУБД PostgresPro под высокой нагрузкой: процесс представлял собой массированную многопоточную заливку данных на протяжении многих часов,а данных было около 20 ТБ, потоков — 75.

В процессе загрузки наблюдалось следующее явление: через некоторое время процесс checkpointer переставал делать контрольные точки в зависимости от других параметров БД либо сразу, либо через 2-3 часа.

Эта история начиналась с процесса валидации 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 механизмах исполнения.