SQL-Ex blog - PostgreSQL

Правильный способ предоставить доступ к вашей базе данных PostgreSQL стороннему администратору

nospam@example.com (mssqlhelp) — Fri, 04 Sep 2026 13:24:00 +0300

SHRIDHAR KHANAL: The Right Way to Give a Third-Party DBA Access to Your PostgreSQL Database

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

За эти годы я был по обе стороны этого разговора. Я был внешним администратором, которого подключали к базе данных клиента, и я был внутренним инженером, решающим, какой доступ предоставить. Шаблон, который я собираюсь вам показать, — это тот, к которому я бы прибег в любой из этих ситуаций: специально созданная, не-суперпользовательская роль, которая даёт внешней команде ровно то, что им нужно для реальной работы, и ничего лишнего.

Continue reading "Правильный способ предоставить доступ к вашей базе данных PostgreSQL стороннему администратору"

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

nospam@example.com (mssqlhelp) — Fri, 04 Sep 2026 11:34:00 +0300

Christophe Pettus: All Your GUCs in a Row: fsync

fsync — это логический параметр, по умолчанию включён, его контекст — sighup, поэтому его можно изменить перезагрузкой конфигурации без перезапуска. Это также самая опасная настройка в postgresql.conf. Большинство параметров из этой серии при неправильной установке стоят вам плохого плана или некоторой потраченной впустую памяти. Этот же параметр при неправильной установке стоит вам кластера.

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

GIN-индексы в PostgreSQL

nospam@example.com (mssqlhelp) — Thu, 03 Sep 2026 18:46:00 +0300

Автор: Klaus Aschenbrenner: GIN Indexes in PostgreSQL

Если вы пришли из SQL Server (как в моём случае), индексы PostgreSQL могут показаться сначала знакомыми — существуют B-tree индексы, составные индексы, покрывающие индексы. А затем вы сталкиваетесь с запросами вроде:

WHERE payload @> '{"type":"payment","status":"failed"}'

или:

WHERE tsv @@ plainto_tsquery('postgresql')

В этот момент большинство разработчиков SQL Server задают два вопроса:

Что это за операторы?

Почему для этого PostgreSQL требуется совершенно другой тип индекса?

Continue reading "GIN-индексы в PostgreSQL"

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

nospam@example.com (mssqlhelp) — Thu, 03 Sep 2026 12:13:00 +0300

Christophe Pettus: All Your GUCs in a Row: from_collapse_limit

Почти никто не использует форму запроса, которой управляет этот параметр:

SELECT * FROM x, y, (SELECT * FROM a, b, c WHERE something) AS ss

WHERE somethingelse;

Но вы постоянно создаёте её, не желая того. Ссылка на представление, содержащее соединение, приводит к тому, что определение представления подставляется вместо ссылки, и планировщик видит именно это: подзапрос в вашем списке FROM. Вложенные представления, SQL, сгенерированный ORM, и всё, что построено из многократно используемых фрагментах запросов, попадает к планировщику в этой форме. from_collapse_limit решает, что планировщик будет с этим делать.

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

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

nospam@example.com (mssqlhelp) — Wed, 02 Sep 2026 14:46:00 +0300

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

file_extend_method — это «запасной выход» в тушке регулятора настройки. Он существует для одной цели: позволить вам отключить оптимизацию PostgreSQL 16 на тех файловых системах, где эта оптимизация вела себя некорректно.

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

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

nospam@example.com (mssqlhelp) — Tue, 01 Sep 2026 12:51:00 +0300

Christophe Pettus: All Your GUCs in a Row: file_copy_method

file_copy_method — это перечисление из двух значений с совершенно невероятной отдачей. Одна из его настроек позволяет копировать базу данных примерно за долю секунды, независимо от того, имеет ли база данных размер один гигабайт или один терабайт. Другая — это способ, которым PostgreSQL всегда это делал. Перечисление является новым в PostgreSQL 18, и интересное значение — clone.

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

Обновление PostgreSQL с 9.6 до 17 с помощью pg_upgrade

nospam@example.com (mssqlhelp) — Mon, 31 Aug 2026 17:44:00 +0300

SHRIDHAR KHANAL: Upgrading PostgreSQL 9.6 to 17 with pg_upgrade

При обновлении между основными версиями PostgreSQL есть несколько способов. Дамп и восстановление (dump/restore) — самый простой с точки зрения понимания, но время простоя растёт прямо пропорционально размеру базы данных, поэтому для всего, что больше нескольких терабайт, этот вариант не подходит. Логическая репликация позволяет добиться почти нулевого времени простоя, но она работает только начиная с PostgreSQL 10; если ваш исходный кластер работает на версии ниже 10, этот путь в нативном виде недоступен. Остаётся pg_upgrade — инструмент, поддерживаемый сообществом для обновления основных версий «на месте». С флагом –link он создаёт жёсткие ссылки вместо копирования файлов данных, поэтому сам шаг обновления остаётся быстрым, независимо от размера базы данных.

Эта статья основан на обновлении с версии 9.6 до 17 на Ubuntu с использованием pg_upgrade. Я проведу вас через каждый этап, отмечу моменты, которые застают людей врасплох, и поделюсь проверочными запросами, которые мы выполняем после завершения обновления.

Continue reading "Обновление PostgreSQL с 9.6 до 17 с помощью pg_upgrade"

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

nospam@example.com (mssqlhelp) — Mon, 31 Aug 2026 15:36:00 +0300

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

extra_float_digits — это настройка, чья задача изменилась под ней. На протяжении большей части истории PostgreSQL она принуждала к выбору между выводом чисел с плавающей точкой, который был удобен для чтения, и выводом, который был абсолютно точным, и нельзя было иметь и то, и другое. Начиная с PostgreSQL 12 вам больше не нужно выбирать, поэтому параметр, к которому вы, возможно, привыкли прибегать, теперь вам редко понадобится.

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

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

nospam@example.com (mssqlhelp) — Sat, 29 Aug 2026 13:47:00 +0300

Christophe Pettus: All Your GUCs in a Row: external_pid_file

PostgreSQL уже записывает PID-файл. Каждый раз при запуске postmaster он помещает postmaster.pid в каталог данных и удаляет его при чистом завершении работы. Этот файл является блокировкой, которая предотвращает запуск второго postmaster с тем же каталогом данных, и содержит восемь строк с деталями работающего экземпляра: PID, каталог данных, время запуска, порт, каталог сокетов и так далее. external_pid_file не заменяет его. Он просит postmaster записать второй, гораздо меньший файл в другом месте.

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

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

nospam@example.com (mssqlhelp) — Fri, 28 Aug 2026 15:39:00 +0300

Christophe Pettus: All Your GUCs in a Row: extension_control_path

На протяжении всей истории PostgreSQL до настоящего момента расширение должно было находиться ровно в одном месте. CREATE EXTENSION foo читал foo.control из встроенного каталога расширений, на который указывает pg_config --sharedir, и нигде больше не искал. Если вы хотели, чтобы расширение было доступно, его файлы должны были находиться в этом каталоге, что на практике означало установку от root в системное дерево или встраивание в образ. extension_control_path, новый в PostgreSQL 18, отменяет это допущение.

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

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

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

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

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

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

Что означают .ready и .done, и почему WAL задерживается

nospam@example.com (mssqlhelp) — Wed, 26 Aug 2026 16:17:00 +0300

Автор: Richard Yen, A practical guide to what .ready and .done mean, and why WAL sticks around

9:12 утра в понедельник. Кто-то из вашей команды открывает каталог pg_wal/archive_status/ во время паники по поводу хранилища и видит длинный список файлов, оканчивающихся на .ready. Возникает вопрос, который многие из нас задавали хотя бы раз: «Сломалась ли репликация?» Потоковые реплики всё ещё выглядят в основном нормально, но файлы .ready продолжают накапливаться, использование диска продолжает расти, и никто до конца не уверен, что на самом деле означают .ready и .done.

Что такое .ready и какие (если вообще какие) действия мне нужно предпринять? Давайте поговорим об этом сегодня.

Подсказка: Это о доставке WAL

Представьте доставку WAL как три независимых шага:

Генерация WAL

Транспортировка WAL

Воспроизведение или потребление WAL

archive_command — это один из способов транспортировки. Потоковая репликация — другой. Обратите внимание, что логическая репликация также имеет канал транспортировки, но она транспортирует декодированные данные логических изменений, а не сырые файлы сегментов WAL.

Continue reading "Что означают .ready и .done, и почему WAL задерживается"

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

nospam@example.com (mssqlhelp) — Wed, 26 Aug 2026 11:09:00 +0300

Christophe Pettus: All Your GUCs in a Row: event_triggers

Событийный триггер (event trigger) срабатывает на события базы данных, а не на изменения строк: на ddl_command_start, sql_drop, table_rewrite и, начиная с PostgreSQL 17, на login. Они используются для аудита DDL или наложения запрета на DDL, и они идут с хорошо известным способом выстрелить себе в ногу. Напишите триггер на ddl_command_start, функция которого вызывает исключение, и теперь каждая команда DDL в базе данных завершается ошибкой, включая DROP EVENT TRIGGER, который вы использовали бы для его удаления. Документация содержит ровно этот пример — функцию abort_any_command, настроенную на прерывание всего, предположительно для того, чтобы вы узнали форму ошибки, когда уже её совершили.

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

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

nospam@example.com (mssqlhelp) — Tue, 25 Aug 2026 16:04:00 +0300

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

event_source — это параметр для Windows, что означает, что для большинства читающих это не делает ровно ничего. Если вы запускаете PostgreSQL на Linux или в управляемом сервисе, там нет журнала событий Windows, с которым он мог бы взаимодействовать, и эта строка навсегда остаётся со значением по умолчанию. То, что следует далее, предназначено для меньшинства пользователей Windows, и сводится к одному факту, который стоит знать.

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

Посмотрим, что делает VACUUM на уровне страницы

nospam@example.com (mssqlhelp) — Sat, 22 Aug 2026 13:12:00 +0300

Автор: Radim Marek: VACUUM at the Page Level

В статье о HOT-обновлениях в Postgres мы рассмотрели, как обрезка страниц (page pruning) очищает HOT-цепочки — элегантное сокращение, с помощью которого PostgreSQL освобождает место мёртвых кортежей во время обычных операций чтения. И всё это без ожидания фонового процесса. Но обрезка — это именно сокращение. Она работает только в пределах одной страницы и только для кортежей, обновлённых через HOT. Для всего остального (холодные обновления, затрагивающие индексированные столбцы, обычные DELETE, очистка записей индексов, регистрация в карте свободного пространства, обслуживание карты видимости) необходим VACUUM.

Эта статья не будет повторять то, что VACUUM делает с эксплуатационной точки зрения. Статья DELETEs are difficult охватывает настройку autovacuum, распределение рабочих процессов и эксплуатационную сторону очистки мёртвых кортежей. Здесь мы будем наблюдать за работой VACUUM побайтово. Мы сделаем снимок страницы до и после каждого этапа, отслеживая, что именно меняется в заголовке страницы, указателях строк, заголовках кортежей, карте свободного пространства и карте видимости. Инструменты всё те же: pageinspect, pg_visibility и pg_freespacemap.

Continue reading "Посмотрим, что делает VACUUM на уровне страницы"

VACUUM — это ложь (о ваших индексах)

nospam@example.com (mssqlhelp) — Mon, 24 Aug 2026 19:33:00 +0300

Автор: Radim Marek: VACUUM Is a Lie (About Your Indexes)

Существует распространённое заблуждение, которое беспокоит большинство разработчиков, использующих PostgreSQL: настройте VACUUM или запустите VACUUM, и ваша база данных останется здоровой. Мёртвые кортежи будут очищены. Идентификаторы транзакций переработаны. Пространство освобождено. Дальнейших действий не требуется.

Но есть пара «грязных» секретов, о которых люди не знают. Первый из них заключается в том, что VACUUM лжёт вам о ваших индексах.

Continue reading "VACUUM — это ложь (о ваших индексах)"

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

nospam@example.com (mssqlhelp) — Mon, 24 Aug 2026 17:26:00 +0300

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

escape_string_warning включён по умолчанию уже около двадцати лет, и на современном PostgreSQL, настроенном обычным образом, он никогда не скажет вам ни слова. Это не неисправность. Условие, о котором он предупреждает, перестало быть поведением по умолчанию в 2011 году.

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

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

nospam@example.com (mssqlhelp) — Sun, 23 Aug 2026 16:44:00 +0300

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

enable_tidscan — это параметр enable_*, который вы почти наверняка никогда не установите, и на этот раз это не предупреждение, а просто факт о том, как происходят сканирования TID. Вы не натыкаетесь на него случайно, как на последовательное сканирование или сортировку. Сканирование TID появляется только тогда, когда вы явно написали условие на ctid, поэтому тип плана, которым управляет этот параметр, появляется именно тогда, когда вы его запросили, и никак иначе.

(Для протокола: я за всю свою жизнь ни разу не видел узел tidscan.)

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

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

nospam@example.com (mssqlhelp) — Sat, 22 Aug 2026 13:02:00 +0300

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

Обращение к enable_sort = off, потому что в запросе есть медленная сортировка, обычно бьёт мимо цели. Когда сортировка медленная, это обычно происходит из-за того, что она сбрасывается на диск, что является проблемой work_mem. Если сортировки вообще не должно быть, исправление — это индекс. enable_sort не изменяет ни одного из этих факторов, и его отключение редко бывает тем, что вам действительно нужно.

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

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

nospam@example.com (mssqlhelp) — Fri, 21 Aug 2026 18:27:00 +0300

Christophe Pettus: All Your GUCs in a Row: enable_seqscan

enable_seqscan не отключает последовательные сканирования. Он не может этого сделать, и никогда не был для этого предназначен. В документации прямо сказано: последовательные сканирования невозможно полностью подавить, потому что иногда чтение всей таблицы является единственным способом ответить на запрос. На самом деле, значение off говорит планировщику избегать последовательного сканирования, только когда у него есть любая другая альтернатива. Это диагностическая инструкция, а не конфигурационная, и это различие — весь смысл данного параметра.

По умолчанию включён, контекст — пользовательский. Вы отключаете его в сессии, чтобы задать вопрос планировщику. Вы никогда не отключаете его в postgresql.conf, и мы объясним почему.

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

Анализ причин бага контрольной точки PostgreSQL

nospam@example.com (mssqlhelp) — Thu, 20 Aug 2026 19:13:00 +0300

Автор: Warda Bibi, Inside a PostgreSQL Checkpointer Bug: A Production Postmortem

В одной из производственных баз данных PostgreSQL 16.8 нашего клиента в журнале начала появляться ошибка, похожая на ошибку памяти:

ERROR: invalid memory alloc request size

Ошибка сразу указывала на двух вероятных виновников:

Исчерпание памяти

Повреждение памяти

Как оказалось, ни то, ни другое не было причиной. Вместо этого мы столкнулись с известной ошибкой PostgreSQL, которая заперла процесс контрольной точки (checkpointer) в бесконечном цикле повторных попыток. Единственным способом восстановления была принудительная перезагрузка, за которой последовало длительное воспроизведение WAL во процессе аварийного восстановления.

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

Continue reading "Анализ причин бага контрольной точки PostgreSQL"

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

nospam@example.com (mssqlhelp) — Thu, 20 Aug 2026 16:41:00 +0300

Christophe Pettus: All Your GUCs in a Row: enable_self_join_elimination

Вы редко являетесь единственным, кто пишет ваш SQL. Ваша ORM пишет часть его, ваши вложенные представления пишут ещё больше, и рано или поздно одно из них соединяет таблицу саму с собой по её собственному первичному ключу. Это соединение возвращает ровно те строки, с которых началось. enable_self_join_elimination — это оптимизация PostgreSQL 18, которая замечает и удаляет такое соединение.

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

Сброс последовательности PostgreSQL: объяснение START With против RESTART With или SETVAL

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

Пересказ статьи PostgreSQL Sequence Reset: START WITH vs RESTART WITH vs SETVAL Explained

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

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

Мы использовали экспорт SEQUENCE_VALUES в ora2pg для генерации команд DDL, чтобы установить последние значения последовательностей.

Пример команды Ora2pg для экспорта DDL последовательности. Continue reading "Сброс последовательности PostgreSQL: объяснение START With против RESTART With или SETVAL"

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

nospam@example.com (mssqlhelp) — Wed, 19 Aug 2026 17:53:00 +0300

Christophe Pettus, All Your GUCs in a Row: enable_presorted_aggregate

enable_presorted_aggregate включён, он включён с момента появления в PostgreSQL 16, и самое полезное, что вы когда-либо сделаете с ним, — это отключите его ровно для одного запроса.

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

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

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

nospam@example.com (mssqlhelp) — Tue, 18 Aug 2026 14:45:00 +0300

Christophe Pettus, All Your GUCs in a Row: enable_partitionwise_join

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

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

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

nospam@example.com (mssqlhelp) — Mon, 17 Aug 2026 16:04:00 +0300

Christophe Pettus, All Your GUCs in a Row: enable_partition_pruning

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

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

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

nospam@example.com (mssqlhelp) — Sun, 16 Aug 2026 11:49:00 +0300

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

Оптимизация для секционирования и примечательное исключение в семействе enable_*: по умолчанию она выключена. Почти все остальные члены семейства по умолчанию включены и существуют для того, чтобы вы могли отключить возможность для диагностики; этот же по умолчанию выключен и существует для того, чтобы вы могли включить его, когда решите, что оно стоит затрат. Это обратное поведение — и стоимость, которая его мотивирует, — составляют суть данного поста. Контекст — пользовательский. И в отличие от большинства членов семейства, изменение этого параметра — это легитимное решение по настройке, а не просто диагностический зонд.

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

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

nospam@example.com (mssqlhelp) — Sun, 16 Aug 2026 12:03:00 +0300

Christophe Pettus, All Your GUCs in a Row: enable_parallel_hash

Переключатель для параллельных запросов, уточняющий хэш-соединение из статьи про enable_hashjoin, и он требует точности, потому что «хэш-соединение, выполняемое параллельно» и «параллельное хэш-соединение» — это две действительно разные вещи. По умолчанию включён, контекст пользовательский, и он относится к тому же семейству, что и enable_async_append: это диагностический инструмент, а не регулятор настройки.

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

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

nospam@example.com (mssqlhelp) — Sat, 15 Aug 2026 14:09:00 +0300

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

Возвращаемся к параллельным запросам и параметру, который легко спутать с первым в этом семействе. enable_async_append был посвящён параллельному выполнению внешних сканирований на удалённых серверах. Параметр enable_parallel_append касается параллельного выполнения локальных дочерних узлов Append на рабочих процессах. Разный механизм, другая задача, похожее название. По умолчанию включён, контекст пользовательский, и он относится к тому же семейству: это диагностический инструмент, а не регулятор настройки.

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

Слишком много таблиц — это плохо

nospam@example.com (mssqlhelp) — Sat, 15 Aug 2026 13:45:00 +0300

Автор: Laurenz Albe, Too many tables are bad for you

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

Continue reading "Слишком много таблиц — это плохо"

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

nospam@example.com (mssqlhelp) — Thu, 13 Aug 2026 18:55:00 +0300

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

Последний из трёх переключателей стратегий соединения и в некотором смысле самый важный, потому что вложенный цикл (nested loop) — это одновременно и простейшее соединение в PostgreSQL, и источник самого печально известного катастрофического падения производительности. Три алгоритма были представлены в статье про enable_hashjoin; этот пост завершает серию. По умолчанию включён, контекст — пользовательский, и он относится к тому же семейству, что и enable_async_append: это диагностический инструмент, а не регулятор настройки.

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

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

nospam@example.com (mssqlhelp) — Wed, 12 Aug 2026 17:18:00 +0300

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

Второй из трёх переключателей стратегий соединения. Три алгоритма были изложены в статье про enable_hashjoin — вложенный цикл, соединение слиянием и хэш-соединение, — так что здесь мы углубимся в средний из них. По умолчанию включён, контекст — пользовательский, и он относится к тому же семейству, что и enable_async_append: это диагностический инструмент, а не регулятор настройки.

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

Обновление кластеров PostgreSQL 19 стало ещё более бесшовным

nospam@example.com (mssqlhelp) — Tue, 11 Aug 2026 17:38:00 +0300

Автор: Vigneshwaran C , Closing a critical gap in PostgreSQL upgrade workflows with sequence synchronization

Обновление кластеров PostgreSQL 19 стало более плавным благодаря таким инструментам, как pg_upgrade и pg_createsubscriber, которые вместе обеспечивают обновление с практически нулевым временем простоя, сначала преобразуя физические реплики в логических подписчиков, а затем выполняя обновление с минимальным прерыванием обслуживания.

Однако этот подход обнажает давний пробел в логической репликации: состояние последовательностей (sequence state) не реплицируется.

В этой статье мы рассмотрим реальный сценарий обновления, покажем, где именно всё может пойти не так, и объясним, как новая функция синхронизации последовательностей в PostgreSQL 19 делает весь процесс безопасным для промышленной эксплуатации.

Узнайте, как PostgreSQL 19 улучшает процессы обновления благодаря внедрению синхронизации последовательностей, обеспечивая безопасные и бесшовные переходы при обновлении баз данных.

Continue reading "Обновление кластеров PostgreSQL 19 стало ещё более бесшовным"

Всё о GUC по порядку: enable_material и enable_memoize

nospam@example.com (mssqlhelp) — Tue, 11 Aug 2026 11:42:00 +0300

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

Два переключателя enable_* для двух узлов плана, которые оба, условно говоря, кешируют строки, чтобы избежать повторных вычислений, — именно поэтому их путают, и именно поэтому их стоит рассматривать вместе. Они не являются вариациями одной идеи. Materialize — это «тупой» буфер; Memoize — это «умный» кеш. Суть этого поста — чётко зафиксировать это различие. Оба параметра включены по умолчанию, оба относятся к пользовательскому контексту, и оба находятся в том же семействе, что и enable_async_append: это диагностические инструменты, а не регуляторы настройки производительности.

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

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

nospam@example.com (mssqlhelp) — Mon, 10 Aug 2026 13:51:00 +0300

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

Третий способ использования индекса, после обычного индексного сканирования и сканирования битовой карты из enable_indexscan и enable_bitmapscan, — и тот, у которого есть наиболее неправильно понимаемый «подвох», потому что сканирование только по индексу может быть физически возможным, но всё равно заканчиваться чтением кучи почти для каждой строки. Почему это происходит, и есть суть этого поста. По умолчанию включён, контекст — user, с тем же обрамлением семейства, что и у enable_async_append: диагностический инструмент, а не регулировочная ручка.

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

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

nospam@example.com (mssqlhelp) — Fri, 07 Aug 2026 11:57:00 +0300

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

Действительно хорошая функциональность скрывается за этим переключателем, что делает его одним из наиболее интересных параметров семейства enable_* для понимания, — и одним из немногих, у кого есть известный сценарий отказа, который стоит распознавать. По умолчанию включён, контекст — user, с тем же обрамлением семейства, что и у enable_async_append: диагностический инструмент, а не регулировочная ручка. Инкрементальная сортировка появилась в PostgreSQL 13 (Томаш Вондра и Джеймс Коулман), и когда она помогает, она помогает очень сильно.

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

pg_stats: как работает внутренняя статистика Postgres

nospam@example.com (mssqlhelp) — Thu, 06 Aug 2026 13:24:00 +0300

Автор: Richard Yen, pg_stats: How Postgres Internal Stats Work

Недавно мне выпала честь выступить на POSETTE 2026 с докладом о pg_stats и о том, как работает внутренняя статистика Postgres (запись на YouTube). Эта статья является письменным дополнением к тому докладу и предназначен для того, чтобы дать вам рабочее понимание того, что такое pg_stats, как он заполняется и как он влияет на решения, которые планировщик запросов принимает от вашего имени.

Continue reading "pg_stats: как работает внутренняя статистика Postgres"

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

nospam@example.com (mssqlhelp) — Thu, 06 Aug 2026 21:23:00 +0300

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

Первый из трёх переключателей стратегий соединения, поэтому прежде чем перейти к параметру, — один абзац о том, внутри чего он находится: в PostgreSQL есть ровно три способа соединения двух таблиц, и для каждого соединения в каждом запросе планировщик выбирает один из них. Три переключателя enable_* для соединений — этот, enable_mergejoin и enable_nestloop — позволяют вам убрать один вариант со стола и посмотреть, что планировщик выберет вместо него. То же правило семейства, что и всегда (enable_async_append): диагностические инструменты, а не регулировочные ручки. По умолчанию включён, контекст — user.

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

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

nospam@example.com (mssqlhelp) — Tue, 04 Aug 2026 18:03:00 +0300

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

Переключатель параллельных запросов и один из наиболее интересных членов семейства enable_* для переключения, потому что то, что он отключает, имеет чистое, предсказуемое замещение. По умолчанию включён, контекст — user, с тем же предостережением семейства, что и у enable_async_append: диагностический инструмент, а не регулировочная ручка.

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

Оптимизация полиморфных ассоциаций в PostgreSQL

nospam@example.com (mssqlhelp) — Tue, 04 Aug 2026 13:57:00 +0300

Автор: Андрей Лепихов,Optimising Polymorphic Associations in PostgreSQL

Недавно я исследовал, насколько распространены полиморфные ассоциации в реляционных базах данных — это враждебный производительности паттерн, построенный вокруг дискриминированного внешнего ключа, который автоматически генерируют ORM (Rails, Django, Hibernate), CRM-платформы (Salesforce) и 1C. Главная страница типичного интернет-магазина или лента активности CRM построены именно на таком запросе: базовая таблица соединяется через LEFT JOIN со всеми возможными подтипами через пару столбцов (type, id).

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

Спойлер: пока немногое реализовано — но кое-что движется в pgsql-hackers. Три патча, обсуждавшихся в 2024–2026 годах, нацелены на три разных источника снижения производительности. Каждый из них описан ниже.

Continue reading "Оптимизация полиморфных ассоциаций в PostgreSQL"

Всё о GUC по порядку: enable_distinct_reordering и enable_group_by_reordering

nospam@example.com (mssqlhelp) — Mon, 03 Aug 2026 11:27:00 +0300

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

Два самых молодых члена семейства enable_* и естественная пара: оба позволяют планировщику переупорядочивать ключи многоключевой операции, чтобы удешевить сортировку, и оба включены по умолчанию, имеют контекст user и несут предостережение семейства enable_* из enable_async_append — диагностические зонды, а не производственные регулировочные ручки.

Идея, стоящая за обоими, одна и та же, и она хороша. Когда вы пишете GROUP BY a, b, c или SELECT DISTINCT a, b, c, порядок, в котором вы перечислили эти столбцы, не несёт семантического смысла, — группировка и поиск уникальных значений дают один и тот же результат независимо от того, какой ключ сравнивается первым. Но порядок имеет огромное значение для стоимости. Если операция выполняется путём сортировки, сравнение сначала дешёвого для сравнения столбца с высокой кардинальностью означает, что большинство сравнений завершаются на первом ключе и никогда не затрагивают остальные; начните с дорогого текстового столбца с учётом локали, и вы заплатите стоимость его сравнения для каждой строки. А если другая часть запроса — ORDER BY, индекс, уже выдающий строки в определённом порядке, — хочет получить данные, отсортированные определённым образом, согласование с этим порядком позволяет планировщику повторно использовать сортировку, которую он всё равно собирался выполнить, или полностью пропустить её с помощью incremental sort. Таким образом, планировщик, получив свободу переставлять ключи, порядок которых не влияет на корректность, иногда может найти значительно более дешёвую схему, чем та, которую вы написали.

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

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

Всё о GUC по порядку: enable_indexscan и enable_bitmapscan

nospam@example.com (mssqlhelp) — Thu, 30 Jul 2026 14:17:00 +0300

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

Ещё два переключателя планировщика из семейства enable_*, и они идут вместе, потому что то, что они отключают, в обоих случаях является индексом, — разница заключается в том, как используется индекс. Оба включены по умолчанию, оба имеют контекст user, и оба несут предупреждение из семейства параметров enable_* от enable_async_append: это диагностические инструменты, а не регулировочные ручки. Вы переключаете их в сеансе, чтобы увидеть второй выбор планировщика, а не в postgresql.conf, чтобы принудительно навязать своё решение.

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

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

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

nospam@example.com (mssqlhelp) — Tue, 21 Jul 2026 09:44:00 +0300

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

Мы подошли к семейству параметров enable_* — более чем двум десяткам переключателей планировщика, которые по умолчанию включены и объединены одним важнейшим свойством: они не являются регулировочными ручками. Это диагностические инструменты. Каждый из них отключает способность планировщика рассматривать определённый тип плана, и причина, по которой такая возможность существует, заключается в том, чтобы инженер, преследующий «плохой» план, мог заставить планировщик показать свою вторую альтернативу, — спросить: «Что бы ты сделал, если бы этот тип узла был недоступен?» Отключение одного из них в рабочей среде для ускорения запроса почти всегда является ошибкой; на самом деле вы хотите понять, почему планировщик предпочёл план, который вам не понравился, и эти переключатели — способ его «допроса». Каждая статья в этом семействе будет повторять некоторую версию этого предупреждения, потому что каждый из этих параметров используется неправильно одинаковым образом.

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

Истории про отказ multixact из-за циклического переполнения, повреждение TOAST и оборванные страницы

nospam@example.com (mssqlhelp) — Sun, 19 Jul 2026 13:51:00 +0300

Автор: Payal Singh,Postgres War Stories Part 2: multixact wraparound, TOAST corruption, and torn pages

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

Первая часть была посвящена сбоям, которые начинаются на уровень ниже Postgres: ядро, glibc, аллокатор страниц. Эта статья — о худшем классе, когда сбой происходит внутри самого Postgres. Журналы чисты. Восстановление никогда не запускается. И запрос либо возвращает неверный ответ, либо «роняет» строки, которые всё ещё лежат на диске.

Три инцидента ниже не имеют ничего общего, кроме того, что делает их опасными: нет ошибки, на которую можно было бы настроить оповещение. Переполнение счётчика multixact, отсутствующий фрагмент TOAST, оборванная страница на диске — ничто из этого не подаёт сигнала. База данных не знает, что она неверна. Вы либо планируете задачу, которая будет это искать, либо узнаёте об этом, когда пользователь сообщает, что строки, которую он клянётся, что она была, больше нет.

Так что эта статья — наполовину про инциденты, наполовину про обнаружение. Обнаружение — вот в чём суть.

Continue reading "Истории про отказ multixact из-за циклического переполнения, повреждение TOAST и оборванные страницы"

Почему в Postgres нет synchronous_commit=remote_receive?

nospam@example.com (mssqlhelp) — Sat, 18 Jul 2026 13:22:00 +0300

Автор: Robins Tharakan,Why Postgres Doesn't Have synchronous_commit=remote_receive?

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

Идея remote_receive родилась из простого вопроса: даёт ли пропуск записи на диск на резервном сервере измеримый, реальный прирост производительности? Ожидая только получения байтов WAL в памяти резервного сервера, можно ли получить значительное улучшение по сравнению с remote_write? Я взялся реализовать и протестировать эту возможность, чтобы выяснить это.

За этим последовало путешествие по задержкам сети, кэшу страниц ОС, «перегрузке» планировщика ЦП и шуму при бенчмаркинге. Вот подробности реализации, тестов, первоначальных аномалий и итоговых результатов.

Continue reading "Почему в Postgres нет synchronous_commit=remote_receive?"

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

nospam@example.com (mssqlhelp) — Sun, 19 Jul 2026 13:13:00 +0300

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

Большинство параметров, меняющихся между версиями, меняют своё значение по умолчанию. effective_io_concurrency — более редкий случай: он дважды менял своё значение, и то, чем он управляет в PostgreSQL 18, отличается от того, чем он управлял в 17, что в свою очередь отличалось от того, что он означал до 13. Значение, скопированное вами из руководства по настройке 2019 года в современный кластер, не просто устарело — оно может отвечать на вопрос, который PostgreSQL больше не задаёт. Поэтому этот параметр лучше всего объяснять в виде истории. Текущее состояние, чтобы задать точку отсчёта: значение по умолчанию — 16, контекст — user, диапазон от 0 до 1000, где 0 отключает функцию.

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

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

nospam@example.com (mssqlhelp) — Sat, 18 Jul 2026 12:34:00 +0300

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

Это один из наиболее последовательно неправильно понимаемых параметров PostgreSQL, и непонимание всегда имеет одну и ту же форму: люди верят, что effective_cache_size что-то делает с памятью. Он выделяет кэш. Он резервирует оперативную память. Он управляет тем, сколько PostgreSQL держит в памяти. Он не делает ничего из этого. Он не выделяет ничего, не резервирует ничего и вообще не меняет поведение во время выполнения. Это всего лишь одно число, переданное планировщику запросов, и его единственный эффект — изменять то, какие планы планировщик считает дешёвыми. Значение по умолчанию — 4 ГБ, контекст — user, и он заслуживает большего, чем обычное количество слов, потому что ошибиться с ним так легко и это так тихо и дорого обходится.

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

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

nospam@example.com (mssqlhelp) — Fri, 17 Jul 2026 17:04:00 +0300

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

dynamic_shared_memory_type выбирает механизм операционной системы, который PostgreSQL использует для динамической разделяемой памяти — памяти, выделяемой после запуска, в отличие от фиксированной области shared_buffers, которая выделяется один раз при загрузке. Контекст — postmaster, поэтому для изменения требуется перезапуск, а значение по умолчанию выбирается initdb в зависимости от поддержки вашей платформы: posix в Linux и большинстве Unix, windows в Windows. Вероятно, вы никогда не будете устанавливать его намеренно. Однако вы можете столкнуться с проблемой в контейнере, и это часть, заслуживающая вашего внимания.

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

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

nospam@example.com (mssqlhelp) — Thu, 16 Jul 2026 22:09:00 +0300

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

dynamic_library_path указывает PostgreSQL, где искать загружаемый C-модуль, когда что-то — CREATE FUNCTION ... LANGUAGE C, команда LOAD, запись в shared_preload_libraries — указывает библиотеку по простому имени файла без пути. Значение по умолчанию — $libdir, контекст — superuser, и большую часть своей жизни этот параметр был тем, к чему никто не прикасался. PostgreSQL 18 дал ему повод снова стать важным, и к этому мы в итоге и придём.

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

Столбцы JSONB и TOAST в Postgres: пособие по производительности

nospam@example.com (Sergey Moiseenko) — Thu, 16 Jul 2026 09:03:00 +0300

Пересказ статьи Paul Ramsey. Postgres JSONB Columns and TOAST: A Performance Guide

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

Работа с API и массивами с типом данных jsonb становится все более популярной в настоящее время, и хранение фрагментов данных приложения с использованием jsonb становится общим шаблоном проектирования.

Но зачем разбивать объект JSON на строки и столбцы, а затем восстанавливать его позже, чтобы отправить обратно клиенту?

Ответом является эффективность. PostgreSQL наиболее эффективен при работе со строками и столбцами, и сокрытие структуры данных внутри JSON не позволяет движку работать так быстро, как он мог бы.
Continue reading "Столбцы JSONB и TOAST в Postgres: пособие по производительности"