Skip to content

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

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


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


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

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

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


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

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

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

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


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



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



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

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

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

Автор: 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"

IDENTITY или SEQUENCE в SQL Server – что использовать?

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


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


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

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

Новости за 2026-07-25 - 2026-07-31

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


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

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

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

Автор		Сообщений
pegoopik 6
gennadi_s 3
Продолжить чтение "Новости за 2026-07-25 - 2026-07-31"

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

Автор: 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"

Проблемы параллелизма SQL Server с планами одновременно выполняющихся запросов

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


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

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

Ответы на вопросы относительно удаленных столбцов

Пересказ статьи Cláudio Silva. Answering Questions On Dropped Columns


В этой статье я отвечу на пару вопросов из предыдущих публикаций об удалении столбцов.

Если вы не читали предыдущих постов по этой теме, вот их список:

Комментарии


В разделе комментариев к первой статье читатель спрашивает:

Можно ли считать, что будущие вставки (после удаления столбца) не будут занимать пространство удаленного столбца?

и еще

Если страница перезаписывается (например, в результате обычной вставки или обновления), используется ли тогда повторно пространство, занимаемое удаленным столбцом?
Продолжить чтение "Ответы на вопросы относительно удаленных столбцов"
Категории: T-SQL

Оптимизация заданий загрузки данных в SQL Server: стратегии реализации в рабочей среде

Пересказ статьи Arvind Toorpu. Optimizing Data Loader Jobs in SQL Server: Production Implementation Strategies


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

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


Продолжить чтение "Оптимизация заданий загрузки данных в SQL Server: стратегии реализации в рабочей среде"

Как читать файл JSON в Python в 2026 году на примерах

Пересказ статьи Sherry walker. How to Read JSON File in Python with Examples in 2026


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


Продолжить чтение "Как читать файл JSON в Python в 2026 году на примерах"

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

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


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

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

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

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


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


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



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



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

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

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

Автор: 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 отключает функцию.

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