Одной из самых важных причин выбрать платформу как службу (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 (только таблица).
Там мы тестировали лишь простую, не секционированную таблицу. А что будет, если таблица секционирована?
Язык структурированных запросов (SQL) — основа манипулирования и извлечения данных в современных базах. Будь то MySQL, PostgreSQL, SQL Server или Oracle, SQL предоставляет мощные инструменты для эффективной работы с данными. Среди них важнейшую роль в упрощении сложных операций играют Common Table Expressions (CTE) и подзапросы.
Однако многие разработчики — особенно начинающие — задаются вопросом, чем именно отличаются CTE от подзапросов, когда выбирать одно вместо другого и как каждый влияет на читаемость, производительность и сопровождение.
В SQL подзапросы вместе с CTE позволяет разбивать сложную логику на более компактные и управляемые части. Часто достигая одинаковых результатов, они различаются структурой, повторным использованием и пригодностью для разных задач. Выбор подходящего инструмента (CTE или подзапросов) зависит от сложности запроса, необходимости повторного использования и простоты читаемости кода.
Это руководство подробно разбирает разницу между CTE и подзапросами в SQL, с примерами, вариантами применения и советами по оптимизации, которые сделают вас более эффективным SQL‑разработчиком.
Работая над проектом, связанным с PostgreSQL, я столкнулся со странной проблемой:
Я создал новую копию базы данных (xyz_copy) из существующей (xyz), кроме того, я создал новую роль с именем root. Я думал, что сделал все правильно, предоставляя root полный доступ:
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO root;
GRANT USAGE ON SCHEMA public TO root;
ALTER TABLE abc ADD COLUMN test_column TEXT;
ERROR: must be owner of relation abc
Выборка данных является обычным требованием, применимым ко многим реальным рабочим нагрузкам SQL Server, пытаетесь ли вы протестировать подмножество данных, выполняете просмотр записей перед экспортом, или строите небольшую копию таблицы для разработки, выборка становится необходимым инструментом. SQL Server предлагает оператор TABLESAMPLE, который на первый взгляд выглядит простым и многообещающим. Написав запрос типа select top 100 from Orders tablesample 10 percent, вы естественно ожидаете, что SQL Server вернет 10 процентов случайных строк. К сожалению, это не так работает.
Предложение TABLESAMPLE работает не с отдельными строками, а с физическими страницами данных. Это означает, что SQL Server пытается вернуть строки из приблизительно 10 процентов от общего числа страниц, а не строк. Если ваши данные равномерно распределены и каждая страница заполнена, это может дать вам результаты, близкие к 10 процентам строк. Но в реальности, благодаря фрагментации, обновлениям и удалениям, большинство страниц содержат различное число строк. Именно тут TABLESAMPLE становится весьма непредсказуемым. Давайте смоделируем эту ситуацию на простом примере для демонстрации поведения на практике. Continue reading "От строк к страницам: скрытый хаос в методах выборки внутри SQL Server"
