При планировании миграции баз данных в PostgreSQL именно мелочи часто становятся причиной самых серьёзных сбоев в рабочей среде. Одна из самых распространённых ловушек для разработчиков — это различная обработка значений NULL и пустых строк ('') в разных СУБД.
Хотя они могут казаться схожими концепциями, обозначающими отсутствие значения, то, как механизм базы данных их интерпретирует, может изменить результаты ваших запросов, нарушить уникальные ограничения или привести к сбоям загрузки данных. В этом руководстве мы сравним поведение Oracle, SQL Server и PostgreSQL, чтобы помочь вам избежать распространённых ошибок миграции.
Блокировки на уровне строк часто являются узким местом в производительности в среде баз данных с высокой конкуренцией. Когда транзакция ожидает блокировку на конкретную строку, это может привести в действие цепь задержек, которые трудно диагностировать. К счастью, PostgreSQL предоставляет мощный инструмент в модуле contrib, чтобы вытащить на свет эти неуловимые блокировки: pgrowlocks.
В этом руководстве мы представим практический подход к использованию pgrowlocks. Мы начнем с установки расширения с последующей имитацией блокировки, чтобы увидеть ее в действии и, наконец, построим мощную глобальную функцию для идентификации блокировок уровня строки по всей базе данных с данными о пользователе, запросе и продолжительности. Continue reading "Как обнаружить и устранить конфликты на уровне строк в PostgreSQL с помощью pgrowlocks"
PostgreSQL может чрезвычайно хорошо масштабироваться в производственной среде, но многие развертывания работают на консервативных значениях по умолчанию, которые безопасны, но далеки от оптимальных. Суть оптимизации производительности заключается в том, чтобы понимать, что на самом деле контролирует каждый параметр, как параметры взаимодействуют в условиях параллельной работы и как проверять влияние с помощью реальных метрик.
Это руководство проведёт вас через два самых важных параметра памяти:
Начиная с PostgreSQL 17, сообщество базы данных получило долгожданную функцию: инкрементные бэкапы. Наряду с этим появился новый инструмент, pg_combinebackup, который играет важную роль в создании этих резервных копий на практике.
Запрос выполняется всего за 2 миллисекунды, но этап его планирования занимает 500 мс. База данных имеет разумный размер, запрос затрагивает 9 таблиц, а default_statistics_target установлен всего в 500. Откуда такое несоответствие?
Этот вопрос недавно был поднят в списке рассылки pgsql-performance, и расследование выявило несколько неожиданного виновника: статистика столбцов, хранящаяся в таблице pg_statistic PostgreSQL.
