SQL-Ex blog - Articles

Всё о GUC по порядку: debug_* family

nospam@example.com (mssqlhelp) — Thu, 11 Jun 2026 10:31:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: the debug_* family

Двенадцать параметров имеют префикс debug_, и этот префикс является значимым: это собственные средства разработки и контроля качества PostgreSQL, предоставленные в виде настроек времени выполнения, чтобы сборочная ферма (buildfarm) и разработчики ядра могли тестировать пути кода без перекомпиляции. Pavlo Golub, пишущий об одном из них, подвёл итог правильному подходу: «Я никогда-никогда не буду трогать параметр времени выполнения с префиксом “debug” в своих производственных кластерах». В основном это правильно. Давайте разберём дюжину параметров и то, что они на самом деле дают, потому что один или два тихо полезны, а остальными стоит восхищаться с безопасного расстояния.

Continue reading "Всё о GUC по порядку: debug_* family"

Зло (и польза) DISTINCT

nospam@example.com (Sergey Moiseenko) — Tue, 09 Jun 2026 16:16:00 +0300

Пересказ статьи Louis Davidson. The evil (and value) of DISTINCT

Есть ли в SQL ключевое слово, которое вызывало бы больший страх, чем DISTINCT. Когда я вижу его в запросе, то сразу начинаю беспокоиться о том, сколько работы мне предстоит сделать, чтобы убедиться в правильности этого запроса. Я начинаю искать комментарии, объясняющие, почему оно тут находится, и если не обнаруживаю, то знаю, что запрос, вероятно, будет неправильным.

Я наблюдал такие DISTINCT, которые скрывали плохие соединения, отсутствующую группировку и даже пропущенные предложения WHERE. Я видел разработчиков, которые использовали его как "универсальное решение" проблем с данными.

В этой статье я рассмотрю правильное и явно опасное использование DISTINCT, а также покажу, как вы можете протестировать ваш запрос, который использует DISTINCT, чтобы увидеть, что он на самом деле скрывает.
Continue reading "Зло (и польза) DISTINCT"

Всё о GUC по порядку: bgwriter_delay и bgwriter_flush_afte

nospam@example.com (mssqlhelp) — Sun, 07 Jun 2026 13:23:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: bgwriter_delay and bgwriter_flush_after

Кластер параметров на букву B меняет направление: от разовых странностей к параметрам фонового процесса записи (background writer), которых насчитывается четыре GUC. Первые два мы рассмотрим как пару, потому что bgwriter_delay знакомит нас с самим процессом, а bgwriter_flush_after органично вписывается в экскурсию по механизму writeback из статьи про backend_flush_after.

Continue reading "Всё о GUC по порядку: bgwriter_delay и bgwriter_flush_afte"

Обзор индексов в MySQL: B-Tree индексы FULLTEXT

nospam@example.com (Sergey Moiseenko) — Sun, 07 Jun 2026 08:37:00 +0300

Пересказ статьи Lukas Vileikis. MySQL Index Overviews FULLTEXT B-Tree Indexes

Что такое полнотекстовое индексирование?

Полнотекстовые индексы - это особый тип индекса, который позволяет быстро и эффективно выполнять поиск по данным, используя довольно экзотические режимы поиска. В MySQL эти режимы включают, но не ограничиваются ими, логический режим, режим естественного языка и режим поиска с использованием расширения запроса. Некоторые из режимов поиска, ставшие возможными благодаря использованию полнотекстовых индексов, предоставляют уникальную поддержку для различной интерпретации определенных символов, поиска подразумеваемых данных и других специфических нюансов.

Полнотекстовое индексирование работает аналогичным образом во многих системах управления базами данных и существенно не менялось годами - загляните в блог Роберта Шелдона, посвященного полнотекстовому поиску более двух десятилетий назад, и вы конечно найдете что-нибудь, что изменилось в вашей установке SQL Server, но вы также обнаружите множество вещей, которые остались неизменными; и то же самое можно сказать о других системах управления базами данных.
Continue reading "Обзор индексов в MySQL: B-Tree индексы FULLTEXT"

Всё о GUC по порядку: backslash_quote

nospam@example.com (mssqlhelp) — Sat, 06 Jun 2026 11:28:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: backtrace_functions

Параметр для разработчиков (developer option) и действительно полезный. backtrace_functions принимает разделённый запятыми список имён внутренних C-функций; если ошибка возникает внутри любой функции из списка, PostgreSQL записывает трассировку стека на уровне C (C-level stack trace) в журнал сервера вместе с ошибкой. Добавлен в PostgreSQL 13. Значение по умолчанию — пустая строка. Контекст — superuser (или любой пользователь с соответствующим привилегией SET). Доступен не на всех платформах, и качество вывода зависит от того, как был скомпилирован PostgreSQL.

Это необычная область для оператора — это параметр для исследования исходного кода самого сервера, когда что-то идёт не так, а не для настройки поведения. Но если вы когда-либо смотрели на ошибку ERROR: tuple concurrently updated или cache lookup failed for relation NNNNN и задавались вопросом «откуда это в исходном коде», это инструмент для вас.

Continue reading "Всё о GUC по порядку: backslash_quote"

Всё о GUC по порядку: backslash_quote

nospam@example.com (mssqlhelp) — Fri, 05 Jun 2026 17:22:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: backslash_quote

Первый исторический артефакт в кластере параметров на букву B. backslash_quote управляет тем, принимается ли \' как способ представления одиночной кавычки внутри строкового литерала SQL. Он существует из-за уязвимости SQL-инъекции 2006 года, связанной с многобайтовыми кодировками символов, и почти двадцать лет спустя он всё ещё находится в списке GUC, потому что его удаление нарушило бы работу какого-нибудь приложения где-то. PostgreSQL консервативен в таких вопросах.

Continue reading "Всё о GUC по порядку: backslash_quote"

TOAST — куда PostgreSQL прячет большие значения

nospam@example.com (mssqlhelp) — Fri, 05 Jun 2026 15:38:00 +0300

Автор: Radim Marek, TOAST: Where PostgreSQL hides big values

Каждый кортеж кучи (heap tuple) живёт внутри страницы размером строго 8 КБ. Всё остальное построено поверх этого жёсткого ограничения: MVCC, HOT update и индексы, указывающие на (страница, указатель_строки). И тем не менее, это всё ещё работает:

CREATE TABLE docs (id int PRIMARY KEY, body jsonb);

INSERT INTO docs VALUES (1, (SELECT jsonb_agg(g) FROM generate_series(1, 100000) g));

Это значение body где-то за полмегабайта. Страница кучи по-прежнему имеет размер 8 КБ. Оба утверждения истинны одновременно, и механизм, который позволяет им сосуществовать, называется TOAST: The Oversized-Attribute Storage Technique (техника хранения чрезмерно больших атрибутов).

Continue reading "TOAST — куда PostgreSQL прячет большие значения"

Всё о GUC по порядку: backend_flush_after

nospam@example.com (mssqlhelp) — Thu, 04 Jun 2026 16:18:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: backend_flush_after

Мы открываем кластер параметров на букву B параметром, само существование которого является признанием сложных отношений. У PostgreSQL сложные отношения с кэшем страниц Linux (page cache), и backend_flush_after — один из четырёх GUC, которые существуют для управления этими отношениями. Остальные три — bgwriter_flush_after, checkpoint_flush_after и wal_writer_flush_after — получат свои собственные статьи в своё время. Они используют общий механизм и имеют общую мотивацию, и эту мотивацию стоит понять, прежде чем мы погрузимся в конкретный параметр.

Continue reading "Всё о GUC по порядку: backend_flush_after"

Прозрачное шифрование данных и высокая доступность

nospam@example.com (mssqlhelp) — Thu, 04 Jun 2026 17:06:00 +0300

Автор: stormatics.tech, Transparent Data Encryption and High Availability

Прозрачное шифрование данных (Transparent Data Encryption, TDE) стало обязательным требованием для многих предприятий, хранящих конфиденциальные данные, будь то персональные или финансовые. Однако этот эффект обычно означает, что резервные копии бесполезны без отдельного хранимого ключа шифрования, а запуск самого сервера может не выполняться в полностью автоматизированном режиме (в зависимости от того, как настроено управление ключами). Взаимодействие между этими компонентами не всегда интуитивно понятно. Данная статья призвана внести ясность.

Этот документ по планированию содержит базовое введение или обзор как высокой доступности, так и прозрачного шифрования данных, а затем даёт обзор операционных проблем, связанных с совместным использованием этих двух технологий. Рекомендации касаются как инфраструктуры, которую следует учитывать, так и процессов, которые необходимо документировать, тестировать и отрабатывать.

Continue reading "Прозрачное шифрование данных и высокая доступность"

SSL в PostgreSQL: введение в шифрование подключений к базе данных

nospam@example.com (mssqlhelp) — Thu, 04 Jun 2026 15:26:00 +0300

Автор: Shridhar Khanal, SSL in PostgreSQL

«"SSL включён" и "SSL действительно работает" — это две большие разницы».

Continue reading "SSL в PostgreSQL: введение в шифрование подключений к базе данных"

Всё о GUC по порядку: autovacuum_worker_slots

nospam@example.com (mssqlhelp) — Wed, 03 Jun 2026 10:43:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: autovacuum_worker_slots

Последняя запись в кластере параметров автовакуума и самая новая. PostgreSQL 18 представил autovacuum_worker_slots для решения давней операционной проблемы: изменение autovacuum_max_workers ранее требовало перезапуска сервера, что делало невозможным реагирование на меняющуюся рабочую нагрузку вакуума без окна обслуживания. PG 18 исправляет это, разделяя параметр на две части.

Continue reading "Всё о GUC по порядку: autovacuum_worker_slots"

wal_level, который вы установили, — это не тот wal_level, который вы получите

nospam@example.com (mssqlhelp) — Wed, 03 Jun 2026 10:04:00 +0300

Автор: Christophe Pettus, The wal_level You Set Is Not the wal_level You Get

С тех пор как в PostgreSQL существует логическая репликация, правило было таковым: если вы когда-нибудь захотите её использовать, установите wal_level = logical при запуске сервера и живите с объёмом WAL вечно. Стоимость не была катастрофической, но она была постоянной. Установите один раз — платите всегда, включая 364 дня в году, когда вы не использовали ни одного логического слота.

PostgreSQL 19 меняет это. Параметр всё ещё существует. Он просто больше не совсем то, что вы установили.

Continue reading "wal_level, который вы установили, — это не тот wal_level, который вы получите"

Всё о GUC по порядку: autovacuum_work_mem

nospam@example.com (mssqlhelp) — Tue, 02 Jun 2026 17:47:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: autovacuum_work_mem

autovacuum_work_mem задаёт максимальный объём памяти, который каждый рабочий процесс автовакуума может использовать для отслеживания идентификаторов мёртвых кортежей (TID — tuple identifier) во время вакуума. Значение по умолчанию: -1, что означает «унаследовать от maintenance_work_mem». Контекст параметра — sighup. Этот параметр существует для того, чтобы потребление памяти автовакуумом можно было настраивать независимо от памяти, используемой ручным VACUUM, CREATE INDEX, REINDEX и другими разовыми операциями обслуживания.

Continue reading "Всё о GUC по порядку: autovacuum_work_mem"

Делаем JSONB более удобным для запросов с помощью генерируемых столбцов

nospam@example.com (mssqlhelp) — Tue, 02 Jun 2026 14:54:00 +0300

Автор: Richard Yen, Making JSONB More Queryable with Generated Columns

За последний год я работал в нескольких контекстах, управляя большими объёмами данных, хранящихся в формате JSONB в PostgreSQL. Сценарий обычен: пользователи ценят гибкость документо-ориентированной модели хранения, избегая необходимости предопределять схемы или постоянно мигрировать структуры таблиц по мере изменения их требований к данным. JSONB-документы могут быть глубоко вложенными с многочисленными необязательными полями и масштабироваться до сотен килобайт на запись без проблем. Однако, когда приходит время запрашивать эти документы — фильтровать по идентификатору пользователя, типу события, временным меткам или вложенным свойствам действий — запросы могут стать медленными и/или неудобными для работы.

Проблема, которую я хочу решить: «Как сделать поиск по JSONB-данным более эффективным, не разбивая наши документы и не вставляя их в столбцы реляционной базы данных?» В Postgres доступно несколько подходов, каждый со своими компромиссами. Я надеюсь пролить свет на эти подходы в этой статье.

Continue reading "Делаем JSONB более удобным для запросов с помощью генерируемых столбцов"

Всё о GUC по порядку: autovacuum_vacuum_scale_factor и autovacuum_vacuum_threshold

nospam@example.com (mssqlhelp) — Mon, 01 Jun 2026 18:08:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: autovacuum_vacuum_scale_factor and autovacuum_vacuum_threshold

Классическая пара параметров запуска вакуума, наконец. Последние несколько статей мы потратили на параметры, которые изменяют, ограничивают или дополняют формулу запуска, управляемую этими двумя; теперь мы добрались до оригиналов.

Формула:

порог_вакуума = autovacuum_vacuum_threshold

                 + autovacuum_vacuum_scale_factor × reltuples

Когда количество устаревших кортежей (обновлённых или удалённых строк) с момента последнего вакуума превышает это значение, автовакуум планирует выполнение VACUUM для таблицы. В PostgreSQL 18 и новее результат также ограничивается параметром autovacuum_vacuum_max_threshold. Значения по умолчанию: autovacuum_vacuum_threshold = 50, autovacuum_vacuum_scale_factor = 0.2. Оба параметра имеют контекст sighup, и для каждого существуют переопределения на уровне таблицы через параметры хранения.

Continue reading "Всё о GUC по порядку: autovacuum_vacuum_scale_factor и autovacuum_vacuum_threshold"

Оптимизация поиска при использовании SQL LIKE с подстановочными знаками

nospam@example.com (Sergey Moiseenko) — Sat, 30 May 2026 23:09:00 +0300

Пересказ статьи Simon Liew. Optimize SQL LIKE Wildcard Searches

Полный поиск по шаблону (например, LIKE '%поисковая_фраза%') в Microsoft SQL Server может быть медленным и неэффективным, поскольку гарантируется сканирование всех строк в таблице. Имеются ли какие-нибудь варианты оптимизации запросов с оператором SQL LIKE?

Оптимизация независимого от регистра полного поиска по шаблону с начальным и конечным подстановочным знаком является проблемой в базах данных SQL - эти шаблоны LIKE не получают выгоды от индексирования. Здесь исследуются потенциальные варианты оптимизации такого поиска и проверяются распространенные заблуждения.
Continue reading "Оптимизация поиска при использовании SQL LIKE с подстановочными знаками"

Всё о GUC по порядку: autovacuum_vacuum_max_threshold

nospam@example.com (mssqlhelp) — Fri, 29 May 2026 11:41:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: autovacuum_vacuum_max_threshold

Новинка в PostgreSQL 18. Этот параметр является первоклассным исправлением проблемы, с которой всё сообщество боролось около пятнадцати лет: на очень больших таблицах стандартная формула запуска вакуума ждёт абсурдно долго, прежде чем что-либо сделать.

Исходная формула:

порог_вакуума = autovacuum_vacuum_threshold

                 + autovacuum_vacuum_scale_factor × reltuples

При значениях по умолчанию — autovacuum_vacuum_threshold = 50 и autovacuum_vacuum_scale_factor = 0.2 — таблица на 100 миллионов строк ждёт 20 миллионов мёртвых кортежей, прежде чем запустится вакуум. Таблица на миллиард строк ждёт 200 миллионов. К моменту, когда вакуум действительно запускается, у вас уже огромное количество раздувания (bloat), сам вакуум занимает часы, а следующий запускается из такого же плохого состояния.

Классическим обходным решением (workaround) была покадровая настройка autovacuum_vacuum_scale_factor для каждой таблицы до значений вроде 0.02 или 0.005, которую мы обсудим, когда доберёмся до этих параметров в следующей статье. Это работает, но требует предварительного выявления каждой большой таблицы и назначения ей индивидуальных параметров хранения (storage parameters). Легко забыть, легко упустить, когда маленькая таблица вырастает в большую.

Continue reading "Всё о GUC по порядку: autovacuum_vacuum_max_threshold"

Всё о GUC по порядку: autovacuum_vacuum_insert_scale_factor и autovacuum_vacuum_insert_threshold

nospam@example.com (mssqlhelp) — Thu, 28 May 2026 14:00:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: autovacuum_vacuum_insert_scale_factor and autovacuum_vacuum_insert_threshold

Эти два параметра образуют третью согласованную пару в комплекте автовакуума, после пары для ANALYZE и пары для обычного вакуума (последняя будет рассмотрена следующей). Они управляют тем, когда автовакуум запускает VACUUM для таблицы на основе количества вставок (INSERT) с момента последнего вакуума — не обновлений, не удалений, только вставок. Они были добавлены в PostgreSQL 13 и существуют для решения конкретной проблемы.

Continue reading "Всё о GUC по порядку: autovacuum_vacuum_insert_scale_factor и autovacuum_vacuum_insert_threshold"

Вы обеспечили выборы лидера в Patroni, но это только начало пути к высокой доступности PostgreSQL

nospam@example.com (mssqlhelp) — Thu, 28 May 2026 12:31:00 +0300

Автор: Umair Shahid, You have a Patroni leader election. You are only halfway to PostgreSQL high availability

Первичный сервер PostgreSQL теряет питание в 2 часа ночи. Запись возобновляется менее чем за тридцать секунд. Дежурный инженер читает оповещение утром, видит, что кластер восстановился самостоятельно, и возвращается к кофе. Это тот результат, который должна обеспечивать высокая доступность PostgreSQL.

Работающий кластер Patroni сам по себе доводит вас лишь до половины пути. Выборы лидера работают. Резервный сервер (standby) повышается до первичного. Состояние кластера в etcd остаётся согласованным. Затем приложение продолжает пытаться подключиться к IP-адресу, который теперь указывает на неправильный узел, старый первичный сервер требует ручного повторного присоединения (rejoin), и дежурный инженер оказывается на конференц-связи, а не в постели.

Я видел этот шаблон достаточно часто, чтобы назвать его стандартным. Кластер делает свою работу. Приложение ждёт человека. Достаётся инструкция (runbook). Время восстановления (RTO) превышает соглашение об уровне обслуживания (SLA). Все соглашаются после этого, что «нам следует серьёзнее отнестись к высокой доступности».

Continue reading "Вы обеспечили выборы лидера в Patroni, но это только начало пути к высокой доступности PostgreSQL"

Всё о GUC по порядку: autovacuum_naptime, autovacuum_vacuum_cost_delay, autovacuum_vacuum_cost_limit

nospam@example.com (mssqlhelp) — Wed, 27 May 2026 16:47:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: autovacuum_naptime, autovacuum_vacuum_cost_delay, autovacuum_vacuum_cost_limit

Эти три параметра вместе задают темп работы автовакуума: как часто он запускается, как интенсивно работает во время выполнения и как долго приостанавливается, чтобы не монополизировать ваш ввод-вывод. Как и пара параметров autovacuum_analyze_*, их лучше всего понимать как единое целое.

Continue reading "Всё о GUC по порядку: autovacuum_naptime, autovacuum_vacuum_cost_delay, autovacuum_vacuum_cost_limit"

HOT UPDATE в PostgreSQL

nospam@example.com (mssqlhelp) — Wed, 27 May 2026 14:12:00 +0300

Автор: Radim Marek, HOT Updates in Postgres

В предыдущей статье мы видели, как каждое обновление (UPDATE) оставляет после себя мёртвый кортеж. То же поведение «копирования при записи» (copy-on-write) проявляется с операционной точки зрения в статье «DELETEs are difficult». Это плата за MVCC, и если мы имеем дело только с кучей (heap) это терпимо. Проблема в индексах.

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

Heap-Only Tuple (HOT) updates — это механизм PostgreSQL, позволяющий обойти эту проблему. На мой взгляд, это самое изящное оптимизационное решение в движке хранения. Давайте проследим, как именно оно работает.

Continue reading "HOT UPDATE в PostgreSQL"

Всё о GUC по порядку: autovacuum_multixact_freeze_max_age

nospam@example.com (mssqlhelp) — Tue, 26 May 2026 15:52:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: autovacuum_multixact_freeze_max_age

Этот параметр является multixact-эквивалентом autovacuum_freeze_max_age. Механизм параллелен; защищаемый объект — не пространство идентификаторов транзакций (XID), а пространство идентификаторов MultiXact, о котором большинство пользователей PostgreSQL никогда не задумывались, а остальные узнали о нём во время аварии. Итак, перед рассмотрением параметра — краткий обзор multixact.

Continue reading "Всё о GUC по порядку: autovacuum_multixact_freeze_max_age"

Запросы для мониторинга автовакуума

nospam@example.com (mssqlhelp) — Tue, 26 May 2026 13:52:00 +0300

Автор: Laurenz Albe, My queries to monitor autovacuum

За годы обучения, консультирования и поддержки пользователей PostgreSQL я разработал несколько запросов для мониторинга автовакуума. Мониторинг автовакуума — не новое требование, поэтому существует уже много готовых запросов для мониторинга. Однако не все эти запросы полезны. Поэтому я подумал, что будет хорошей идеей написать статью о моей собственной коллекции — как для себя в качестве справочника, так и в качестве услуги для администраторов PostgreSQL по всему миру.

Continue reading "Запросы для мониторинга автовакуума"

Всё о GUC по порядку: autovacuum_max_workerst

nospam@example.com (mssqlhelp) — Mon, 25 May 2026 19:04:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: autovacuum_max_workers

autovacuum_max_workers задаёт максимальное количество фоновых процессов автовакуума (autovacuum worker processes), которые могут выполняться одновременно. Значение по умолчанию — 3. Контекст параметра — postmaster, поэтому его изменение требует перезапуска сервера. Процесс-планировщик (launcher process) является отдельным и не учитывается в этом числе.

Это тот параметр, который кто-то увеличивает с 3 до 10, решив, что автовакуум работает слишком медленно, после чего обнаруживает, что вакуум, как ни странно, на самом деле не стал быстрее. У этого есть причина, и это самое важное, что нужно понять об этом GUC.

Continue reading "Всё о GUC по порядку: autovacuum_max_workerst"

Всё о GUC по порядку: archive_timeout

nospam@example.com (mssqlhelp) — Sun, 24 May 2026 13:28:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: archive_timeout

Архиватор запускается только после завершения сегмента WAL. В загруженной базе данных это происходит постоянно, а в малоактивной — может не происходить часами или даже днями. Параметр archive_timeout предназначен для того, чтобы избежать ситуации вроде «наша база данных весь день принимала операции записи, но ни одна из них ещё не попала в архив».

Continue reading "Всё о GUC по порядку: archive_timeout"

Всё о GUC по порядку: archive_cleanup_command

nospam@example.com (mssqlhelp) — Wed, 20 May 2026 14:04:00 +0300

Автор: Christophe Pettus, All your GUCs in a Row: archive_cleanup_command

Алфавитный порядок выдал нам первую «жертву». archive_cleanup_command — это параметр резервного сервера (standby-server knob), который существует исключительно для того, чтобы прибираться после archive_command. Однако алфавит настаивает на том, чтобы отложить рассмотрение archive_command до следующей статьи. Поэтому мы опишем, как прибирать вечеринку, которую ещё не устраивали.

Кратчайшая предыстория: Первичный сервер PostgreSQL (primary) может архивировать свои сегменты WAL в некоторое место — каталог, корзину S3, общий ресурс NFS — выполняя команду оболочки для каждого заполненного сегмента. Резервные серверы (standbys) читают из этого места, чтобы догонять изменения, а инструменты резервного копирования читают из него для обеспечения восстановления на момент времени (point-in-time recovery, PITR). Файлы накапливаются. Кто-то должен их удалять.

Continue reading "Всё о GUC по порядку: archive_cleanup_command"

Всё о GUC по порядку: archive_library

nospam@example.com (mssqlhelp) — Thu, 21 May 2026 20:46:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: archive_library

Прежде чем погрузиться в этот параметр, небольшое исправление (errata) к предыдущей статье. Я сказал, что инструменты резервного копирования «могут зарегистрироваться как archive_library и полностью обойти archive_command» начиная с PostgreSQL 15+. Именно для этого и была предназначена эта функциональность. Однако это не то, что на самом деле появилось в экосистеме. Подробнее об этом чуть позже.

archive_library, добавленный в PostgreSQL 15, позволяет настроить загружаемый C-модуль для обработки архивации WAL вместо команды оболочки (shell command). Процесс архиватора (archiver process) вызывает колбэки модуля напрямую, внутри своего процесса, один раз на каждый сегмент. Никакого fork(). Никакой оболочки. Никакого cp. PostgreSQL передаёт завершённые WAL-файлы модулю и не будет переиспользовать их, пока модуль не подтвердит успех, — контракт тот же, что и у archive_command, но без накладных расходов и режимов отказа, присущих сценариям оболочки.

Continue reading "Всё о GUC по порядку: archive_library"

Всё о GUC по порядку: archive_mode

nospam@example.com (mssqlhelp) — Fri, 22 May 2026 19:49:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: archive_library

archive_mode — это главный выключатель архивации WAL. После трёх предыдущих статей — archive_cleanup_command, archive_command, archive_library — мы наконец добрались до параметра, который решает, будет ли вообще работать вся эта механика.

Continue reading "Всё о GUC по порядку: archive_mode"

Понимание подзапросов в SQL и построение JSON непосредственно в PostgreSQL

nospam@example.com (Sergey Moiseenko) — Wed, 20 May 2026 11:05:00 +0300

Пересказ статьи Ayomide Ajewole. Understanding Subqueries in SQL and Building JSON Directly in PostgreSQL

Для хорошего бэкенд-разработчика существует определенное стремление к оптимизации запросов (скорости и памяти). Одним из полезных инструментов оптимизации баз данных являются подзапросы SQL.

Подзапрос - это запрос внутри другого запроса. Он позволяет вам вытащить связанные данные или результаты вычислений без написания нескольких запросов или тяжелых соединений. Он также позволяет динамически выполнять вычисления и агрегировать данные.

Имеются разные типы подзапросов в зависимости от типа данных, которые вы хотите вернуть.
Continue reading "Понимание подзапросов в SQL и построение JSON непосредственно в PostgreSQL"

Всё о GUC по порядку: application_name

nospam@example.com (mssqlhelp) — Mon, 18 May 2026 12:44:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: application_name

Большинство GUC в этой серии будут операционно не важны для большинства читателей. Этот — не такой. application_name — это самое дешёвое средство наблюдаемости (observability infrastructure), которое поставляет PostgreSQL, и поразительное количество производственных баз данных работают с неустановленным значением или со значением, застрявшим на значении по умолчанию клиентской библиотеки (psql, PostgreSQL JDBC Driver или, что я люблю больше всего, — пустая строка).

Это метка уровня сеанса (per-session label). Значение по умолчанию — пустая строка, контекст — user, поэтому любая роль может его установить. Установите его через SET application_name = 'order-service';, через параметр подключения application_name или через переменную окружения PGAPPNAME, которую libpq учитывает автоматически. Максимальная длина — NAMEDATALEN - 1 — 63 байта в стандартной сборке, а непечатаемые символы заменяются на ?.

Continue reading "Всё о GUC по порядку: application_name"

Всё о GUC по порядку: allow_system_table_mods

nospam@example.com (mssqlhelp) — Sun, 17 May 2026 15:29:00 +0300

Автор: Christophe Pettus, All your GUCs in a row: allow_system_table_mods

Вот GUC, который поставляется с предупреждающей этикеткой. Документация, обычно сдержанная до степени пародии, прямо заявляет, что неправильная установка этого параметра может привести к «необратимой потере данных или серьёзному повреждению системы базы данных». Когда документация PostgreSQL так повышает голос — прислушайтесь.

Continue reading "Всё о GUC по порядку: allow_system_table_mods"

Слишком много индексов — это сколько?

nospam@example.com (Sergey Moiseenko) — Sun, 17 May 2026 08:22:00 +0300

Пересказ статьи Brent Ozar. How Many Indexes Is Too Many?

Давайте начнем с базы данных Stack Overflow (будет работать версия любого размера), удалим все индексы на таблице Users и выполним DELETE:

SET STATISTICS IO ON;

GO

BEGIN TRAN

DELETE dbo.Users WHERE DisplayName = N'Brent Ozar';

Я использую SET STATISTICS IO ON, о чем мы говорили в статье "Как думать подобно серверу SQL Server" для иллюстрации количества прочитанных данных, и я делаю это в транзакции, которую я могу периодически откатывать, каждый раз демонстрируя полученные эффекты. Вот действительный план выполнения:

Continue reading "Слишком много индексов — это сколько?"

Всё о GUC по порядку: allow_in_place_tablespaces

nospam@example.com (mssqlhelp) — Fri, 15 May 2026 13:21:00 +0300

Автор: Christophe Pettus, All your GUCs in a row: allow_in_place_tablespaces

allow_in_place_tablespaces существует для того, чтобы набор тестов PostgreSQL мог тестировать репликацию. Вот и всё. Если вы читаете это как администратор (оператор), вы никогда к нему не прикоснётесь. Но раз он есть в алфавите, вот мы здесь.

Continue reading "Всё о GUC по порядку: allow_in_place_tablespaces"

Всё о GUC по порядку: allow_alter_system

nospam@example.com (mssqlhelp) — Fri, 15 May 2026 13:15:00 +0300

Автор: Christophe Pettus, All your GUCs in a row: allow_alter_system

GUC — это аббревиатура от Grand Unified Configuration (Великая унифицированная конфигурация).

В контексте PostgreSQL это просто техническое название для всех параметров (настроек) сервера, которые можно менять.

Простыми словами, это переменные, которые определяют, как работает ваш экземпляр PostgreSQL.

Мы начинаем с allow_alter_system — параметра, который одновременно и новый, и политически взрывоопасный. Поэтому давайте начнём со спора.

Команда ALTER SYSTEM была добавлена в PostgreSQL 9.4 как улучшение качества жизни: возможность устанавливать GUC (Grand Unified Configuration — унифицированные параметры конфигурации) из SQL-приглашения, записывая значения в postgresql.auto.conf, без необходимости доступа к оболочке операционной системы. Однако она сразу же вызвала споры среди тех, кто управляет PostgreSQL с помощью систем управления конфигурацией. Если Ansible управляет postgresql.conf, но суперпользователь незаметно выполняет ALTER SYSTEM SET work_mem = '1GB', следующий запуск Ansible не трогает postgresql.auto.conf, и расхождение (дрейф) конфигурации сохраняется бесконечно. Никто не замечает проблемы, пока что-то не сломается.

Этот спор занял примерно десятилетие. В PostgreSQL 17 появился параметр allow_alter_system — булевый параметр, который, когда установлен в off, заставляет ALTER SYSTEM возвращать ошибку: ERROR: ALTER SYSTEM is not allowed in this environment. Значение по умолчанию — on, контекст — sighup, так что для его изменения требуется лишь перезагрузка конфигурации.

Continue reading "Всё о GUC по порядку: allow_alter_system"

10 простых запросов на T-SQL, которые вы будете использовать каждый день

nospam@example.com (Sergey Moiseenko) — Thu, 14 May 2026 08:31:00 +0300

Пересказ статьи rebecca@sqlfingers. 10 T-SQL One-Liners You'll Use Every Day

Каждый администратор баз данных держит в голове инструментарий готовых запросов. Некоторым потребовались годы, чтобы научиться. Некоторые были случайно обнаружены во время работы в 2 часа ночи. Сегодня я поделюсь 10-ю моими самыми любимыми короткими запросами T-SQL, теми, что копируешь, вставляешь и сразу чувствуешь себя гением. Некоторые из них - классические, некоторые - из недавнего пополнения, и все из них полезны. Ставьте закладку, я надеюсь, что вы сюда вернетесь.

1. Генерация числовой последовательности на лету

Нужно быстро получить последовательность чисел без создания таблицы подсчета? Если вы имеете SQL Server 2022 или более позднюю версию, GENERATE_SERIES - ваш новый лучший друг:

SELECT value FROM GENERATE_SERIES(1, 100);

Это все. Одна строка кода. 100 строк в последовательности. Никаких временных таблиц, никаких CTE, никаких перекрестных соединений. Аналогичный прием для диапазона дат. Используйте это для получения каждого дня 2025 года в одной строке:

SELECT DATEADD(DAY, value, '2025-01-01') AS dt FROM GENERATE_SERIES(0, 364);

Версия: SQL Server 2022+ (уровень совместимости 160+)
Continue reading "10 простых запросов на T-SQL, которые вы будете использовать каждый день"

Всё о Huge Pages

nospam@example.com (mssqlhelp) — Tue, 12 May 2026 18:29:00 +0300

Автор: Christophe Pettus, Huge Pages, End to End

Предыдущая статья о регрессии производительности pgbench на Linux 7.0 заканчивалась тем же указанием, которым заканчивается любая другая статья о производительности Postgres: включите huge pages. Эта статья — подробная версия. Если вы читали документацию Postgres о huge_pages, но всё ещё не совсем уверены, что вам говорит /proc/meminfo, какова связь между vm.nr_hugepages и Transparent Huge Pages, или почему huge_pages = try — неправильный выбор, то эта статья для вас.

Здесь не так много нового материала. Однако есть материал, о который люди продолжают спотыкаться, несмотря на то, что он описан в документации.

Continue reading "Всё о Huge Pages"

Потолок масштабирования — когда один экземпляр Postgres пытается заполнить собой всё

nospam@example.com (mssqlhelp) — Mon, 11 May 2026 14:33:00 +0300

Автор: Shaun Thomas, The Scaling Ceiling: When One Postgres Instance Tries to Be Everything

В мире баз данных существует устойчивое убеждение, что вертикальное масштабирование решает все проблемы. Нужна большая пропускная способность? Добавьте ядра ЦП. Заканчивается кэш? Добавьте оперативной памяти. Запросы обращаются к диску? Добавьте операций ввода-вывода в секунду (IOPS). Это утешительная философия, потому что она проста, и на удивление долгое время она работает. Один мощный экземпляр Postgres может выдержать колоссальную нагрузку, прежде чем рухнуть под её давлением.

Но этот потолок существует, и следует он не из аппаратного обеспечения. Postgres был спроектирован как однокомандный движок базы данных, и многие его внутренние структуры являются общими для всех баз данных, которые содержит экземпляр. Эти общие ресурсы редко вызывают беспокойство в одном скромном экземпляре. Но с двадцатью базами данных, работающими со смесью тяжёлых OLTP-нагрузок, аналитических запросов или даже в основном простаивающих, общая природа этих внутренних механизмов становится очень важной.

Давайте поговорим о барьерах, с которыми в конечном итоге сталкиваются такие перегруженные экземпляры, ссылаясь для убедительности на исходный код Postgres. Некоторые из них хорошо известны, другие — из тех, что внезапно поражают в 2 часа ночи, когда все панели мониторинга одновременно становятся красными.

Continue reading "Потолок масштабирования — когда один экземпляр Postgres пытается заполнить собой всё"

Цена проблем с производительностью PostgreSQL

nospam@example.com (mssqlhelp) — Sun, 10 May 2026 17:27:00 +0300

Автор: Annie Ghazali, Cost of PostgreSQL performance issues

PostgreSQL получил широкое распространение благодаря тому, что снимает лицензионные ограничения и даёт таким компаниям, как OpenAI, Lovable и Supabase, надёжную основу для масштабной эксплуатации производственных систем. Однако после развёртывания разговор о стоимости PostgreSQL смещается с лицензирования к тому, насколько эффективно база данных поддерживает выполняемую на ней рабочую нагрузку.

Начальные оптимизации, такие как индексы, дизайн запросов и пути доступа, часто остаются неизменными по мере развития систем. Со временем эти устаревшие решения приводят к неэффективности, вызывая замедления работы и истощение ресурсов. Вместо того чтобы устранять первопричину, команды часто масштабируют инфраструктуру и увеличивают операционные накладные расходы. В результате система продолжает функционировать, но с существенно более высокими затратами, чем необходимо. Если вы понимаете, откуда исходит неэффективность, вы можете исправить её должным образом, а не просто «забрасывать» проблему дополнительными ресурсами.

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

Continue reading "Цена проблем с производительностью PostgreSQL"

Настройка производительности в PostgreSQL 17: как обновления и VACUUM влияют на хранилище

nospam@example.com (Sergey Moiseenko) — Sun, 10 May 2026 10:27:00 +0300

Пересказ статьи Jeyaram Ayyalusamy. 09 - PostgreSQL 17 Performance Tuning: How Updates and VACUUM Affect Storage

Модель хранения в PostgreSQL отличается от многих других баз данных. Вместо переписывания строки по месту, PostgreSQL создает новые версии строк при обновлении данных. Эта схема хороша для безопасности транзакций и параллелизма, но при этом влияет на размер таблицы и VACUUM приобретает важное значение для производительности.

Давайте пошагово пройдем тестовый пример, чтобы увидеть, как это работает на практике.

Отключение autovacuum (только для тестирования)

PostgreSQL обычно выполняет фоновый процесс, который называется autovacuum, для очистки мертвых кортежей и предотвращения раздувания таблиц.

Для реальных приложений выключение autovacuum не рекомендуется, поскольку это критически важно для работоспособности базы данных.

Но в целях тестирования он может быть выключен для конкретной таблицы для гарантии, что ничего не будет происходить автоматически в фоновом режиме.

Это позволяет нам в точности наблюдать, как PostgreSQL управляет хранилищем. Continue reading "Настройка производительности в PostgreSQL 17: как обновления и VACUUM влияют на хранилище"

Понимание запросов списка процессов MySQL: руководство по мониторингу и оптимизации производительности

nospam@example.com (Sergey Moiseenko) — Thu, 07 May 2026 09:46:00 +0300

Пересказ статьи Dmitry Romanoff. Understanding MySQL Process List Queries: A Guide to Monitoring and Optimizing Performance

Таблица MySQL information_schema.processlist предоставляет большой объем информации о текущем состоянии сервера MySQL. Она важна для администраторов и разработчиков баз данных, чтобы мониторить эти данные для обеспечения оптимальной производительности и диагностики потенциальных проблем. В этой статье мы познакомимся с несколькими запросами MySQL, предназначенными для извлечения полезных идей из списка процессов, и обсудим, насколько они могут помочь нам в мониторинге и оптимизации сервера MySQL.

1. Просмотр всех процессов

Чтобы получить исчерпывающий обзор всех текущих процессов на сервере MySQL, вы можете использовать следующий запрос:

SELECT * FROM information_schema.processlist;

Continue reading "Понимание запросов списка процессов MySQL: руководство по мониторингу и оптимизации производительности"

Top 5 форматов резервных копий и когда их использовать в PostgreSQL

nospam@example.com (Sergey Moiseenko) — Tue, 05 May 2026 09:47:00 +0300

Пересказ статьи Pawale. Top 5 Backup Formats and When to Use Them for PostgreSQL

Выбор правильного формата резервной копии может составлять разницу между 10-минутным восстановлением и целым днем мучений. Утилита pg_dump в PostgreSQL предоставляет множество форматов вывода, каждый из которых оптимизирован для различных сценариев - от быстрой разработки снимков до восстановления после сбоев производственных баз. Понимание этих форматов помогает построить такую стратегию восстановления, которая сбалансирует эффективность использования хранилища, скорость восстановления и операционную гибкость. В этом руководстве рассматриваются пять ключевых форматов резервных копий с указанием, когда использовать каждую из них.

Continue reading "Top 5 форматов резервных копий и когда их использовать в PostgreSQL"

Функция JSON_CONTAINS в SQL Server 2025

nospam@example.com (Sergey Moiseenko) — Sun, 03 May 2026 11:32:00 +0300

Пересказ статьи Koen Verbeeck. JSON_CONTAINS Function in SQL Server 2025

У меня есть данные, пришедшие в мой SQL Server в формате JSON. Перед началом парсинга, который довольно интенсивный, необходимо проверить, присутствуют ли некоторые значения в этом JSON. Имеется ли функция, которую я могу использовать с этой целью? Давайте посмотрим, что может делать JSON_CONTAINS, новая функция в SQL Server 2025.

Формат файла JSON поддерживается в SQL Server, начиная с версии 2016, когда были введены функции OPENJSON и JSON_VALUE. Отличное введение в возможности SQL Server 2016 можно найти здесь: Продвинутые методы JSON в SQL Server, часть 1, часть 2 и <часть 3/a>.

С каждый релизом добавляется новая функциональность для обработки данных JSON. Недавно в Azure SQL DB был реализован тип данных JSON, который теперь нашел свое применение в SQL Server 2025. Это последний предварительный релиз SQL Server на момент написания этой статьи. В отличие от многих других новых функций SQL Server, этот предварительный выпуск включает новую функциональность, которая доступна только в SQL Server 2025, но не в облачных аналогах, таких как база данных Azure SQL DB. Одной из этих новых функций является JSON_CONTAINS, которой и посвящена эта статья.
Continue reading "Функция JSON_CONTAINS в SQL Server 2025"

Postgres: более быстрые проверки внешних ключей

nospam@example.com (mssqlhelp) — Fri, 01 May 2026 11:23:00 +0300

Автор: Amit Langote, Postgres: faster foreign key checks

В одной из предыдущих статей я описывал, как работает обеспечение целостности внешних ключей в Postgres. Краткая версия такова: каждая команда INSERT или UPDATE в таблицу, ссылающуюся на другую, запускает триггер AFTER, который проверяет, существуют ли значения столбца внешнего ключа (FK) в ссылочной (PK) таблице. Эта проверка проходит через SPI (Server Programming Interface): строится запрос, он планируется, выполняется, а затем всё уничтожается — для каждой отдельной строки.

Это дорогостоящая операция. При массовой вставке (INSERT) миллиона строк в таблицу с внешним ключом вы выполняете миллион мини-запросов к индексу таблицы первичного ключа. Каждый из них открывает отношение первичного ключа, захватывает снимок (snapshot), выполняет проверку прав, делает поиск по индексу и закрывает всё. Стоимость одной строки в абсолютном выражении невелика, но она очень быстро накапливается.

Для Postgres 19 я применил два патча (соавтором обоих является Джунванг Жао), которые полностью обходят SPI для стандартного случая и выполняют пакетную (batch) проверку индекса. Вместе они ускоряют массовые вставки с внешними ключами примерно в 2.9 раза в используемом мною тесте (int первичный ключ, int внешний ключ, 1 миллион строк, таблица первичного ключа и её индекс в памяти).Что деаёт быстрый путь (fast path) Continue reading "Postgres: более быстрые проверки внешних ключей"

Выбор метода текстового поиска в PostgreSQL

nospam@example.com (mssqlhelp) — Wed, 29 Apr 2026 11:34:00 +0300

Автор: Craig Ringer, Choosing a PostgreSQL text search method

(Эта статья написана применительно к PostgreSQL 9.3. Если вы используете более новую версию, пожалуйста, проверьте, остались ли описанные ограничения в силе.)

PostgreSQL предлагает несколько инструментов для поиска и сопоставления текстовых шаблонов. Сложность заключается в выборе подходящего инструмента для конкретной задачи.

Continue reading "Выбор метода текстового поиска в PostgreSQL"

T-SQL в SQL Server 2025: функции кодирования

nospam@example.com (Sergey Moiseenko) — Wed, 29 Apr 2026 11:19:00 +0300

Пересказ статьи Steve Jones. T-SQL in SQL Server 2025: Encoding Functions

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

Функции кодирования: BASE64_ENCODE и BASE64_DECODE

В язык T-SQL были добавлены две новых функции: BASE64_ENCODE, BASE64_DECODE . Эти функции взаимно обратны, подобно функциям шифрования. Одна функция возвращает вспять действия другого, и они предназначены для совместного использования.
Continue reading "T-SQL в SQL Server 2025: функции кодирования"

PostgreSQL MVCC, байт за байтом

nospam@example.com (mssqlhelp) — Sun, 26 Apr 2026 17:02:00 +0300

Автор: , Radim Marek: PostgreSQL MVCC, Byte by byte

Вы выполняете SELECT * FROM orders в одном сеансе psql и видите 50 миллионов строк. Ваш коллега в другом сеансе выполняет тот же запрос в тот же момент и видит 49 999 999. Никто из вас не ошибается, и никто не видит устаревших данных. Вы оба читаете одни и те же страницы кучи размером 8 КБ, одни и те же байты на диске.

В этом заключается обещание MVCC (многоверсионного контроля конкурентного доступа) PostgreSQL, и именно поэтому читатели никогда не блокируют писателей, а писатели никогда не блокируют читателей. Это также одна из самых неправильно понимаемых частей механизма хранения. Люди знают, что «существует несколько версий строки», и на этом останавливаются.

Continue reading "PostgreSQL MVCC, байт за байтом"

Настройка производительности PostgreSQL 17: индекс BRIN (Block Range INdex)

nospam@example.com (Sergey Moiseenko) — Sun, 26 Apr 2026 08:43:00 +0300

Пересказ статьи Jeyaram Ayyalusamy. 22 - PostgreSQL 17 Performance Tuning: BRIN (Block Range INdex)

При работе с очень большими таблицами в PostgreSQL традиционные индексы типа B-Tree или GiST могут чрезвычайно вырасти в размерах, что занимает значительное время на их обслуживание. Для временных рядов или последовательно упорядоченных данных PostgreSQL предлагает более разумный и облегченный вариант: BRIN (Block Range Index).

Индексы BRIN группируют данные в диапазоны блоков вместо хранения отдельных записей строк, что делает их компактными, быстрыми в построении и эффективными для запросов на диапазон или упорядоченные данные.

Давайте пошагово рассмотрим пример.
Continue reading "Настройка производительности PostgreSQL 17: индекс BRIN (Block Range INdex)"

Как создать связанный сервер в SQL Server для Oracle 26ai Free

nospam@example.com (Sergey Moiseenko) — Thu, 23 Apr 2026 10:20:00 +0300

Пересказ статьи Greg Low. How to Create a SQL Server Linked Server to Oracle 26ai Free

Легко перемещайте данные из SQL Server в Oracle 26ai Free, используя это пошаговое руководство. Узнайте как установить связанный сервер, сконфигурировать FREEPDB1 и избежать типичных ошибок.

Недавно мне пришлось перенести некоторые данные из SQL Server на Oracle 26ai в редакции Free. Я решил проверить, поможет ли связанный сервер сделать эту работу, поскольку зачастую это самый простой способ…

Это позволит мне просто писать операторы INSERT SELECT, но в SQL Server, связанные серверы с Oracle, известны своей неуклюжестью и часто имеют проблемы с некоторыми типами данных, настройками времени, и т. д.

В прошлом мне не приходилось создавать связанный сервер к Oracle 26ai Free, поэтому я решил, что должен задокументировать свои действия, чтобы в будущем я мог легко найти их и, возможно, помочь кому-то еще.
Continue reading "Как создать связанный сервер в SQL Server для Oracle 26ai Free"

DROP COLUMN в PostgreSQL: столбец не удаляется сразу

nospam@example.com (Sergey Moiseenko) — Tue, 21 Apr 2026 17:00:00 +0300

Пересказ статьи Tomasz Gintowt. PostgreSQL DROP COLUMN: It Doesn’t Remove the Column Immediately

При работе со схемами реляционных баз данных вы можете предполагать, что удаление столбца физически удаляет его из табличного хранилища. В PostgreSQL это не всегда так.

Начиная с PostgreSQL 11, операция ALTER TABLE ... DROP COLUMN стала выполняться быстрее, поскольку PostgreSQL больше не переписывает всю таблицу сразу. Напротив, он:

Помечает столбец как удаленный (невидимый и недоступный).

Временно оставляет его данные на диске.

Освобождает хранилище, только когда таблица переписывается (VACUUM FULL, CLUSTER или pg_repack).

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

Continue reading "DROP COLUMN в PostgreSQL: столбец не удаляется сразу"

"Простая" функция, которой нет: миграция функции T-SQL STR() в PostgreSQL

nospam@example.com (Sergey Moiseenko) — Sun, 19 Apr 2026 08:19:00 +0300

Пересказ статьи Assaf Fraenkel. The “Simple” Function That Isn’t: Migrating T-SQL’s STR() to PostgreSQL

Иногда миграция оказывается более сложной, чем ожидалось. На первый взгляд определение функции STR в SQL Server является простым: она возвращает символьное представление числовых данных, выровненные по правому краю с заданной длиной и точностью до десятичных знаков. Однако при попытке конвертации вы обнаруживаете огромное число пограничных случаев, большинство из которых плохо документированы.

Техническая спецификация

Стандартной спецификацией этой функции является:

STR ( float_expression [ , length [ , decimal ] ] )

Значение по умолчанию Length (длина): 10
Значение по умолчанию Decimal (масштаб): 0

Continue reading ""Простая" функция, которой нет: миграция функции T-SQL STR() в PostgreSQL"