SQL-Ex blog

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

nospam@example.com (mssqlhelp) — Wed, 16 Sep 2026 12:38:00 +0300

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

hot_standby_feedback не устраняет проблему. Он перемещает её — с резервного сервера на первичный, и вопрос о том, является ли это хорошим обменом, — это и есть весь вопрос.

Проблема заключается в конфликтах восстановления, которые отменяют долго выполняющиеся запросы на резервном сервере. Резервный сервер воспроизводит изменения первичного, одновременно отвечая на читающие запросы, и когда первичный очищает vacuum мёртвые версии строк, воспроизведение этой очистки на резервном сервере сталкивается с любым запросом, который всё ещё полагается на эти версии. Резервный сервер разрешает столкновение, убивая запрос, и пользователь видит ERROR: canceling statement due to conflict with recovery. hot_standby_feedback останавливает это, прося первичный сервер вообще не удалять эти строки. Стоимость ложится на первичный сервер в виде раздувания, потому что строки, которые он иначе освободил бы, теперь удерживаются запросом, выполняющимся на другой машине.

Именно поэтому он выключен по умолчанию. Значение по умолчанию подразумевает, что запросы резервного сервера не должны иметь возможности «дотянуться» и ограничивать обслуживание первичного. Его включение — это сознательное решение позволить им это.

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

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

Автор Alexey Evlampiev: Your ALTER TABLE Is Fast. The Queue Behind It Is Not

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

Вот один и тот же оператор, выполненный дважды для одной и той же таблицы — PostgreSQL 16.14 в локальном контейнере, таблица orders на 100 000 строк, конкурирующая сессия удерживается открытой через pg_sleep. Это иллюстративные числа с одной машины, а не бенчмарк; важен сам ratio, и вы можете воспроизвести его примерно за минуту.

-- Без конкуренции:

ALTER TABLE orders ADD COLUMN note text;

Time: 5.786 ms



-- С одним обычным долго выполняющимся SELECT, открытым на таблице:

ALTER TABLE orders ADD COLUMN note text;

Time: 18065.050 ms (00:18.065)

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

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

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

Continue reading ""

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

nospam@example.com (mssqlhelp) — Tue, 15 Sep 2026 11:24:00 +0300

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

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

Это логический параметр, по умолчанию включён, его контекст — postmaster, поэтому он фиксируется при запуске сервера. Он включает возможность подключаться к серверу, находящемуся в режиме восстановления, воспроизводящему WAL из архива или от потокового первичного сервера, и выполнять против него запросы только для чтения, пока это воспроизведение продолжается. Часть «только для чтения» обеспечивается принудительно, а не на доверии: любая сессия, подключённая во время восстановления, принудительно переводит свои транзакции в режим только для чтения, что бы клиент ни запрашивал. Функция, которую он включает, — Hot Standby — появилась в PostgreSQL 9.0 и отличает современную читающую реплику от более старого «тёплого резерва» (warm standby), который мог только сидеть и воспроизводить WAL до момента повышения.

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

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

nospam@example.com (mssqlhelp) — Mon, 14 Sep 2026 16:07:00 +0300

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

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

Это строка, её контекст — postmaster, поэтому она фиксируется при запуске сервера, и её можно установить в postgresql.conf. Значение по умолчанию — pg_hba.conf в каталоге данных, куда initdb записывает его при создании кластера. У вас очень редко будет причина его менять, и все возможные причины сводятся к желанию, чтобы файл аутентификации находился где-то вне каталога данных.

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

Как работают пользовательские типы в PostgreSQL: полное руководство

nospam@example.com (Sergey Moiseenko) — Mon, 14 Sep 2026 09:49:00 +0300

Пересказ статьи Grant Fritchey. How User-Defined Types work in PostgreSQL: a complete guide

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

Я уверен, что не одинок, когда говорю: иногда я отвлекаюсь. В данном конкретном случае я не собирался изучать пользовательские типы (UDT) в PostgreSQL — я просто хотел протестировать поведение, связанное с созданием UDT. Но как только я начал читать, меня зацепило. Я имею в виду четыре разных UDT с разным поведением. Это очень круто. Давайте займемся этим.
Continue reading "Как работают пользовательские типы в PostgreSQL: полное руководство"

Почему SUM после JOIN завышает итог — и почему DISTINCT не всегда помогает

nospam@example.com (Sergey Moiseenko) — Fri, 11 Sep 2026 16:10:00 +0300

Автор Глеб Зайцев

В отчёте два оплаченных заказа на 1 600 рублей, а запрос возвращает 2 600. Синтаксис правильный, ошибок выполнения нет. Причина может быть в том, что после соединения таблиц одна и та же сумма заказа встречается несколько раз.

Разберём этот случай на маленькой базе SQLite и проверим исправление не только на удачном примере, но и на пограничных данных. Для запуска полного скрипта в конце статьи нужны Python 3 и встроенный модуль `sqlite3`. Внешняя база, аккаунт и дополнительные пакеты не требуются.
Continue reading "Почему SUM после JOIN завышает итог — и почему DISTINCT не всегда помогает"

Новости за 2026-09-05 - 2026-09-11

nospam@example.com (Sergey Moiseenko) — Fri, 11 Sep 2026 20:29:00 +0300

§ Новая задача от Pegoopik (1 балл) выставлена для обсуждения под номером 303.

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 58 (Learn)		6		6
 207 (SELECT)		2		4
 53 (Learn)		2		6

§ Авторы недели на форуме

Автор		Сообщений
 Steamboat	3
 Murderface_  	3
 Demon_gr	2
 pegoopik  	2
 selber  	2

Continue reading "Новости за 2026-09-05 - 2026-09-11"

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

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

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

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

hash_mem_multiplier — это значение с плавающей точкой, по умолчанию 2.0, контекст — пользовательский, диапазон от 1.0 до 1000. Что он делает, легко сформулировать: операциям на основе хэширования разрешено использовать work_mem, умноженный на это значение, в то время как операции на основе сортировки получают обычный work_mem. При значениях по умолчанию сортировка может использовать 4 МБ, прежде чем сбросить данные на диск, а хэш-таблица может использовать 8 МБ. Под хэш-таблицами здесь понимаются те, что стоят за хэш-соединениями, хэш-агрегацией, узлами memoize и хэш-обработкой подзапросов IN.

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

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

nospam@example.com (mssqlhelp) — Thu, 10 Sep 2026 21:52:00 +0300

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

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

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

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

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

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

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

Из-за этого параметр почти уникален среди GUC. Многие параметры позволяют обменивать один ресурс на другой, а некоторые жертвуют надёжностью ради скорости. Этот же жертвует корректностью ради скорости.

Целочисленный параметр, по умолчанию 0, что означает отсутствие ограничения; контекст user, допустимое значение — до 2147483647.

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

Всё о GUC по порядку: семейство geqo

nospam@example.com (mssqlhelp) — Tue, 08 Sep 2026 11:49:00 +0300

Christophe Pettus: All Your GUCs in a Row: The geqo Family

Семь параметров, одна функция и разумная цель — никогда не использовать ни один из них.

geqo, geqo_threshold, geqo_effort, geqo_pool_size, geqo_generations, geqo_selection_bias и geqo_seed — все они настраивают Генетический оптимизатор запросов (Genetic Query Optimizer), альтернативный поиск порядка соединений, к которому PostgreSQL прибегает, когда в запросе слишком много отношений для полного перебора обычным планировщиком. Все семь параметров имеют контекст user, поэтому любой из них можно установить для сессии, роли или базы данных.

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

Continue reading "Всё о GUC по порядку: семейство geqo"

Как работает многостолбцовая статистика

nospam@example.com (Sergey Moiseenko) — Tue, 08 Sep 2026 08:48:00 +0300

Пересказ статьи Brent Ozar. How Multi-Column Statistics Work

Краткий ответ: в реальных ситуациях работает только первый столбец. Когда SQL Server необходимы данные о втором столбце, он строит вместо этого свою собственную статистику по этому столбцу (предполагая, что ее не существует) и использует эти две статистики совместно - но на самом деле они не связаны.

Чтобы дать более подробный ответ, давайте возьмем большую версию базы данных Stack Overflow, создадим двухстолбцовый индекс на таблице Users, а затем посмотрим на полученную статистику:

DropIndexes;

GO

CREATE INDEX Location_Reputation

    ON dbo.Users(Location, Reputation);

GO

DBCC SHOW_STATISTICS('dbo.Users', 'Location_Reputation');

GO

Вывод DBCC SHOW_STATISTICS показывает, что мы получили 22 миллиона строк в этой таблице. Итак, что гистограмма статистики говорит нам о связи между locations и reputations?

Continue reading "Как работает многостолбцовая статистика"

MVCC в PostgreSQL — это плохо, как и у других

nospam@example.com (mssqlhelp) — Mon, 07 Sep 2026 15:10:00 +0300

Radim Marek: PostgreSQL's MVCC is bad. So is everyone else's

Первое, что вы, вероятно, узнаете о Postgres, если следите за людьми, которым он не нравится, — это то, что MVCC — это плохо. Ошибка дизайна сорокалетней давности. Её признаки повсюду: раздутые таблицы, удваивающиеся в размере, 32-битный лимит счётчика транзакций, бесконечная борьба с VACUUM, кошмары с мёртвыми кортежами. Это подтверждается и авторитетами: Uber измерил амплификацию (здесь - усиление) записи в 2016 году и ушёл на MySQL из-за этого; группа баз данных Энди Павло назвала MVCC частью PostgreSQL, которую они ненавидят больше всего. Это реально. Postgres настолько плох, насколько это возможно.

Хотя всё это не преувеличено, это сводится к реальному дизайнерскому выбору. Раздувание, амплифицированные записи, постоянный уход за VACUUM — все эти обвинения связаны с решением, а не с дефектом, и мы воспроизводим каждое из них ниже на живом экземпляре PostgreSQL 19 beta2, чтобы вы могли увидеть ущерб своими глазами. Но вердикт, который распространяется из сообщества в сообщество, всегда останавливается на один вопрос раньше: по сравнению с чем? Что вместо этого делают все другие движки, и во что это обходится?

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

Где живут старые версии? В самой таблице или в отдельной структуре?

В каком направлении указывают цепочки версий? От старых к новым или от новых к старым?

На что указывают индексы? На физическое расположение строки или на логический ключ?

Кто выполняет очистку и когда? Фоновый процесс позже или сама транзакция?

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

Continue reading "MVCC в PostgreSQL — это плохо, как и у других"

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

nospam@example.com (mssqlhelp) — Mon, 07 Sep 2026 11:36:00 +0300

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

full_page_writes — это логический параметр, по умолчанию включён, его контекст — sighup, устанавливается в postgresql.conf или в командной строке. Это причина, по которой аварийное восстановление вообще работает, и это также причина, по которой ваш график WAL имеет «пилообразную» форму.

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

CONVERT_IMPLICIT: Почему SQL Server игнорирует ваш индекс

nospam@example.com (Sergey Moiseenko) — Sun, 06 Sep 2026 08:44:00 +0300

Пересказ статьи rebecca@sqlfingers. CONVERT_IMPLICIT: Why SQL Server Is Ignoring Your Index

Вы построили индекс и протестировали запрос в SSMS. Index seek. Идеально. Вы пошли домой.

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

Это CONVERT_IMPLICIT - один из наиболее скрытых убийц производительности в SQL Server. Никаких ошибок. Никаких предупреждений в журнале приложения. Запрос возвращает правильные результаты, а ваш индекс отлично структурирован, но оптимизатор его не использует, поскольку тип данных, приходящих из приложения, не соответствует типу данных столбца - и SQL Server должен преобразовывать каждую строку, прежде чем он сможет выполнить сравнение.

Здесь рассказывается, как найти, понять и доказать разработчику, который продолжает говорить вам, что "все прекрасно работает на моей машине". Continue reading "CONVERT_IMPLICIT: Почему SQL Server игнорирует ваш индекс"

Новости за 2026-08-29 - 2026-09-04

nospam@example.com (Sergey Moiseenko) — Fri, 04 Sep 2026 19:10:00 +0300

§ Лидеры недели

	Участник		w_sel	all_sel	select	dml	Всего	Рейтинг
 Цыбин А.В.  (magicdragon)     	4	38	11	3	14	1524
 Шибаев  (saah)                	4	90	9	0	9	537
 Скоков Б.С.  (leks$$)         	4	48	8	0	8	1097
 Виноградова С.М.  (Tigra1)    	2	154	7	0	7	148
 Powkh N.M.  (I_AiLL_I)        	4	4	5	21	26	4141

§ Претенденты на попадание в TOP 100

Рейтинг	 Участник (решенные задачи, время в днях)
 148		Tigra1 (154, 31.674)

Continue reading "Новости за 2026-08-29 - 2026-09-04"

Правильный способ предоставить доступ к вашей базе данных 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"

Зачем использовать составной индекс в SQL Server

nospam@example.com (Sergey Moiseenko) — Wed, 02 Sep 2026 09:06:00 +0300

Пересказ статьи Deepak Vohra. Why use a Composite Index in SQL Server

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

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

Не существует специальной настройки, требуемой для использования составных индексов. SQL Server поддерживает составные индексы. Для демонстрации функциональности я использую SQL Server 2022, исполняемый на Windows 10, с SQL Server Management Studio (SSMS) 2022. Continue reading "Зачем использовать составной индекс в SQL Server"

Всё о 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"

Новости за 2026-08-22 - 2026-08-28

nospam@example.com (Sergey Moiseenko) — Fri, 28 Aug 2026 18:56:00 +0300

§ Лидеры недели

	Участник		w_sel	all_sel	select	dml	Всего	Рейтинг
 Цыбин А.В.  (magicdragon)     	4	34	8	6	14	1799
 Виноградова С.М.  (Tigra1)    	2	152	6	0	6	151
 Скоков Б.С.  (leks$$)         	3	44	5	0	5	1182

§ Претенденты на попадание в TOP 100

Рейтинг	 Участник (решенные задачи, время в днях)
 151		Tigra1 (152, 29.339)

Continue reading "Новости за 2026-08-22 - 2026-08-28"

Новости за 2026-08-22 - 2026-08-28

nospam@example.com (Sergey Moiseenko) — Fri, 28 Aug 2026 18:56:00 +0300

§ Лидеры недели

	Участник		w_sel	all_sel	select	dml	Всего	Рейтинг
 Цыбин А.В.  (magicdragon)     	4	34	8	6	14	1799
 Виноградова С.М.  (Tigra1)    	2	152	6	0	6	151
 Скоков Б.С.  (leks$$)         	3	44	5	0	5	1182

§ Претенденты на попадание в TOP 100

Рейтинг	 Участник (решенные задачи, время в днях)
 151		Tigra1 (152, 29.339)

Continue reading "Новости за 2026-08-22 - 2026-08-28"

Всё о 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"

7 ошибок Python, которые делают ваш код медленным (и как их исправить)

nospam@example.com (Sergey Moiseenko) — Thu, 27 Aug 2026 18:30:00 +0300

Пересказ статьи Sarikasharma. 7 Python Mistakes That Make Your Code Slow (And How to Fix Them)

Когда люди говорят, что Python медленный, они обычно обвиняют язык.

В действительности это часто зависит от того, как мы пишем код.

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

Вот семь распространенных ошибок Python, которые делают ваш код медленней, чем он мог бы быть, и то, как их исправить.
Continue reading "7 ошибок Python, которые делают ваш код медленным (и как их исправить)"

Всё о 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 — это ложь (о ваших индексах)"

Любопытный случай с display(df)

nospam@example.com (Sergey Moiseenko) — Mon, 24 Aug 2026 19:41:00 +0300

Пересказ статьи Karthik. The curious case of display(df)

Вы просто хотите посмотреть ваши данные. Вы быстро набираете display(df) в ячейке notebook и жмете Выполнить. Это кажется совершенно безобидно - кроме того, это всего лишь предварительный просмотр вашего фрейма данных, не так ли?

Но через несколько мгновений ваш кластер начинает вращаться, ячейка работает намного дольше, чем ожидалось, и ваш браузер может даже заикаться.

Хотя display() является фантастическим инструментом для интерактивного исследования, но, если слишком сильно полагаться на него, он может незаметно задушить ваши задания Apache Spark. Давайте заглянем под капот, чтобы точно выяснить, что происходит, когда вы вызываете display(), почему все замедляется, и как простое переключение на show() может радикально улучшить вашу производительность.
Continue reading "Любопытный случай с display(df)"

Всё о 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"

Новости за 2026-08-15 - 2026-08-21

nospam@example.com (Sergey Moiseenko) — Fri, 21 Aug 2026 18:45:00 +0300

§ Изменения среди лидеров рейтинга

Рейтинг	Участник (решенные задачи)
 14		gennadi_s (206)
 35		Шведа Сауля (160)

§ Лидеры недели

	Участник		w_sel	all_sel	select	dml	Всего	Рейтинг
 Шибаев  (saah)                	5	85	12	0	12	622
 Виноградова С.М.  (Tigra1)    	2	150	5	0	5	151
 Саркисьян Г. (gennadi_s)      	1	223	4	0	4	14
 Чвикова А.М.  (Chvikova)      	3	14	4	0	4	5150

§ Претенденты на попадание в TOP 100

Рейтинг	 Участник (решенные задачи, время в днях)
 135		Murderface_ (155, 714.490)
 151		Tigra1 (150, 28.918)

Continue reading "Новости за 2026-08-15 - 2026-08-21"

Всё о 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"

Как узнать последнее значение, используемое последовательностью в SQL Server

nospam@example.com (Sergey Moiseenko) — Sun, 16 Aug 2026 18:30:00 +0300

Пересказ статьи Greg Low. How to determine the last value used by a sequence in SQL Server

Я являюсь фанатом последовательностей с тех пор, когда они появились в SQL Server 2012. До этого у разработчиков был выбор между столбцами IDENTITY и создания собственного механизма для таблиц.

Что такое последовательности в SQL Server?

Последовательности позволяют создавать привязанный к схеме объект, который не связан ни с какой конкретной таблицей.

Например, если у меня есть таблицы Sales.FlightBookings и Sales.VehicleBookings, и я хочу иметь общий BookingID, используемый как ключ для каждой таблицы. Если бы речь шла не только о BookingID, вы могли бы возразить, что существует проблема с нормализацией таблиц, но мы оставим это обсуждение на будущее. Continue reading "Как узнать последнее значение, используемое последовательностью в SQL Server"

Всё о 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"