SQL-Ex blog

Автор: 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 улучшает процессы обновления благодаря внедрению синхронизации последовательностей, обеспечивая безопасные и бесшовные переходы при обновлении баз данных.

Продолжить чтение "Обновление кластеров PostgreSQL 19 стало ещё более бесшовным"

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

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

Продолжить чтение "Всё о GUC по порядку: enable_material и enable_memoize"

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

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

Продолжить чтение "Всё о GUC по порядку: enable_indexonlyscan"

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

Топик		Сообщений	Просмотров
 65 (Learn)		5		7
 Guest's book		3		10
 779 (SELECT)		2		7
 198 (SELECT)		2		6

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

Автор		Сообщений
 selber  	6
 pegoopik  	4
 vencid	2

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

Рейтинг	Участник (решенные задачи)
 15		gennadi_s (204)

Продолжить чтение "Новости за 2026-08-01 - 2026-08-07"

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

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

Продолжить чтение "Всё о GUC по порядку: enable_incremental_sort"

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

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

Продолжить чтение "Всё о GUC по порядку: enable_hashjoin"

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

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

Продолжить чтение "pg_stats: как работает внутренняя статистика Postgres"

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

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

Продолжить чтение "Всё о GUC по порядку: enable_hashagg"

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

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

Продолжить чтение "Всё о GUC по порядку: enable_gathermerge"

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

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

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

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

Продолжить чтение "Оптимизация полиморфных ассоциаций в PostgreSQL"

Автор: 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. Таким образом, планировщик, получив свободу переставлять ключи, порядок которых не влияет на корректность, иногда может найти значительно более дешёвую схему, чем та, которую вы написали.

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

Продолжить чтение "Всё о GUC по порядку: enable_distinct_reordering и enable_group_by_reordering"

Пересказ статьи Greg Low. IDENTITY vs SEQUENCE in SQL Server – which should you use?

Автоматически генерируемые числовые ключи имеются повсюду в реляционных базах данных. В SQL Server доминируют две возможности этого:

• столбцы IDENTITY


• объекты SEQUENCE

Обе генерируют числа. Обе быстры. Обе широко используются. Хотя в настоящее время столбцы IDENTITY являются, безусловно, наиболее распространенными - однако при работе с клиентами мы склонны использовать почти исключительно объекты SEQUENCE. Все, что я могу сделать со столбцом IDENTITY, я могу так же сделать с объектом SEQUENCE, но мы считаем его более гибким.

Вот простой пример. Если вы когда либо пытались выполнить SET IDENTITY_INSERT ON по связанным серверам, то знаете, что это не работает. С SEQUENCE мне никогда не понадобится выполнять такую операцию.
Продолжить чтение "IDENTITY или SEQUENCE в SQL Server – что использовать?"

§ С целью защиты от подгонки автор внес косметические изменения в условие (и решение) задачи 242

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

Топик		Сообщений	Просмотров
 242 (SELECT)		9		3
 181 (SELECT)		3		5

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

Автор		Сообщений
 pegoopik  	6
 gennadi_s  	3

Продолжить чтение "Новости за 2026-07-25 - 2026-07-31"

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

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

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

Продолжить чтение "Всё о GUC по порядку: enable_indexscan и enable_bitmapscan"

Пересказ статьи Mehdi Ghapanvari. SQL Server Concurrency Issues with Parallel Query Plans

Параллелизм может уменьшить способность одновременного выполнения запросов. Это веская причина не позволять SQL Server агрессивно выполнять запросы в параллельном режиме. В этом совете я создам демонстрацию, чтобы показать, что параллелизм снижает производительность запросов на сервере с высоким уровнем конкуренции.

Параллелизм позволяет SQL Server выполнять запросы на нескольких ядрах ЦП одновременно. Оптимизатор запросов определяет, стоит ли выполнять запрос параллельно или нет на основании стоимости. Если запрос сложный, содержит дорогие операции (такие как сортировка, группировка и т.п.) и обрабатывает много строк, то это с большей вероятностью приведет к параллельному плану, чем простой запрос, который обрабатывает несколько строк.
Продолжить чтение "Проблемы параллелизма SQL Server с планами одновременно выполняющихся запросов"