Вы испытываете сложности при переходе от 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"
