Раздувание индексов в PostgreSQL может вызывать проблемы, но его легко пропустить.
Я уже писала о том, как проблемы с вакуумированием могут помешать PostgreSQL использовать покрывающие индексы, и раздувание индексов — одна из причин, из-за которой вакууму приходится тяжело.
Эта статья рассказывает о том, что вам нужно знать о раздувании индексов: как его обнаружить и как исправить.
Все мы сталкивались с необходимостью изменить тип данных столбца в таблице. К сожалению, в PostgreSQL вы не можете сделать это за один шаг, если столбец используется в представлении. В этой статье мы опишем действия, необходимые для изменения типа данных столбца в таблице PostgreSQL.
В PostgreSQL, если столбец таблицы имеет зависимости, т.е. используется в представлении, вы получите ошибку, если попытаетесь изменить тип данных или всего лишь длину. Здесь мы увидим способ обойти это ограничение и заскриптовать все зависимости столбца/таблицы.
Поведение PostgreSQL
Чтобы объяснить поведение PostgreSQL, давайте выполним небольшой тест, используя тестовую базу данных Chinook, которую можно свободно загрузить с GitHub для различных СУБД. Это имитация магазина цифровых медиа с образцами данных. Все, что вам нужно сделать, - это загрузить требуемую версию, и вы получите все скрипты создания структуры и вставки данных.
Вы испытываете сложности при переходе от SQL Server к PostgreSQL? В этой серии статей раскрывается важное различие в механизмах двух баз данных: как операторы SELECT и RETURN ведут себя в хранимых процедурах. Давайте разберемся в этом ключевом отличии и сделаем ваш переход более гладким.
SQL — первый язык программирования, в котором появились явные временные типы данных. Я давно полагаю, что если бы в Cobol изначально был тип TIMESTAMP, вся история с Y2K могла бы и не случиться. По крайней мере, сегодня всё больше людей знают о стандартах отображения даты и времени ISO 8601. Кто знает — может быть, их наконец начнут применять.
Одной из самых важных причин выбрать платформу как службу (PaaS), например, AWS RDS, является действительно легкая возможность выполнять восстановление к моменту времени. Давайте посмотрим на это.
Восстановление на момент времени
При подключении к консоли и просмотре ваших баз данных все, что вам требуется сделать - это выбрать вкладку “Maintenance and Backups” (обслуживание и резервные копии) для получения информации о том, какие бэкапы создаются:
Эта статья опирается на предыдущий материал «Введение в NUMA» (PostgreSQL и NUMA, часть 1 из 4) и предполагает не только знание определения NUMA, но и общее понимание аппаратной и программной реализации.
В этой части рассматривается взаимодействие PostgreSQL и Linux на системах с NUMA. Тема сложная, поэтому кое‑где используются упрощения. Тем не менее здесь собрана выжимка общих сведений о работе PostgreSQL 17 и ниже (а также PostgreSQL 18 без поддержки libnuma) на NUMA‑системах с Linux в качестве точки отсчёта. К концу чтения вы не только будете в состоянии уверенно запускать Postgres на NUMA‑системе, но и поймёте, почему поддержка libnuma в PostgreSQL 18 настолько важна.
Этот цикл посвящён особенностям работы PostgreSQL на крупных системах с большим числом процессоров. По моему опыту, столкнувшись с этой задачей, люди нередко тратят месяцы на освоение азов. Цель цикла — снять эти трудности, дав ясную базовую картину по ключевым темам. Хочется верить, что будущим инженерам и администраторам баз данных не придётся месяцами методом проб и ошибок разбираться в том, что можно понять быстрее.
Эти статьи сосредоточены на низкоуровневых «как» и «почему» в контексте неоднородного доступа к памяти (Non‑Uniform Memory Access), чтобы затем было проще понимать решения и рекомендации — с упором на концептуальную сторону. К сожалению, во многих местах без технических деталей не обойтись: голые концепции без деталей в лучшем случае сбивают с толку.
Дальнейшие части будут опираться на материал этой статьи. Рекомендуем начать с него, а затем по мере необходимости возвращаться.
Как я объяснял в докладе на PostgreSQL Conference Europe 2025, повреждение данных может незаметно случиться в любой базе PostgreSQL и останется так, пока мы физически не прочитаем повреждённые данные. Причин, по которым отдельные блоки в таблицах и других объектах могут быть испорчены, немало. Даже современное аппаратное обеспечение хранилищ далеко от безошибочности. Бинарные резервные копии, сделанные инструментом pg_basebackup (очень распространённая стратегия в мире PostgreSQL), скрывают эти проблемы, поскольку они не проверяют данные, а копируют файлы «как есть». С релизом PostgreSQL 18 сообщество решило по умолчанию включить контрольные суммы данных — серьёзный шаг к раннему обнаружению таких сбоев. В этой статье рассматривается, как PostgreSQL реализует контрольные суммы, как обрабатывает их несоответствия и как можно включить контрольные суммы в существующих кластерах.
Оператор MERGE позволяет написать один оператор DML с различными условиями для выполнения операций INSERT, UPDATE или DELETE в целевой таблице на основе источника данных. Он обеспечивает ряд преимуществ в плане производительности и не требует исключения или ограничения уникальности, в отличие от оператора INSERT ON CONFLICT.
Давайте рассмотрим пример с таблицей current_inventory, которую мы хотим обновить на основе транзакций, перечисленных в таблице daily_updates. Нам необходимо учесть все состояния (sale, new, remove, restock) в таблице daily_updates и выполнить необходимые операции с current_inventory.
Кроме того, мы реализуем функциональность обновления значения поля addinfo на “no sale” в current_inventory, если элемент отсутствует в daily_updates. Continue reading "Оператор Merge в PostgreSQL 17"
Однажды, отлаживая патч для исправления утечки памяти в Postgres 12, я неплохо разобрался с тем, какие кэши используются внутри Postgres и как устроена внутренняя механика их аннулирования, когда закэшированное содержимое устаревает. Запишу детали, пока они ещё в доступной области памяти.
Postgres хранит данные, которые вставляются в таблицы, в файлах. Для каждой таблицы есть свой файл (строго говоря, больше одного, если таблица превышает 1 ГБ), где пользовательские данные записаны в бинарном формате, специфичном для Postgres.
В первой и второй частях мы разобрали, почему на 6‑м выполнении при построении generic‑плана для секционированной таблицы возникает лавина блокировок: планировщик вынужден блокировать все 52 отношения, потому что без значений параметров он не может отсечь секции.
Сегодня проверим, что происходит при разных значениях настройки plan_cache_mode.
Понимание структуры, метаданных и объема хранилища ваших таблиц и индексов в PostgreSQL важно для настройки производительности базы данных, аудита и эволюции схемы. Здесь мы рассмотрим важные запросы SQL, чтобы глубже понять:
В первой части мы сосредоточились на поведении Lock Manager при работе с подготовленными выражениями и секционированными таблицами.
В простом синтетическом примере мы увидели взрыв числа блокировок: 8 с custom‑планами в первых пяти вызовах, до 52 с generic‑планом в шестом, и до 13 с использование кэшированного generic‑плана в седьмом и последующих вызовах. Остаются вопросы:
почему именно в 6‑м вызове происходит этот скачок до 52 блокировок, и можно ли его избежать?
почему мы блокируем все 12 секций, хотя во время выполнения 11 из них отсекаются?
В статье "LWLock:LockManager и подготовленные операторы" мы выяснили, что prepared statements могут радикально снизить конкуренцию LWLock:LockManager, переключаясь с блокировок планировщика (которые блокируют всё подряд) на блокировки исполнителя (которые блокируют только то, что действительно используется). Начиная с 7‑го выполнения, мы увидели падение числа блокировок с 6 (таблица + 5 индексов) до всего 1 (только таблица).
Там мы тестировали лишь простую, не секционированную таблицу. А что будет, если таблица секционирована?
