SQL-Ex blog

Автор: 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 с планами одновременно выполняющихся запросов"

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

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

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

• Что происходит при удалении столбца в таблице SQL Server? Где мое пространство?


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


• Сколько места могу я ожидать получить в результате перестройки после удаления столбца?

Комментарии

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

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

и еще

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

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

Топик		Сообщений	Просмотров
 242 (SELECT)		4		2
 241 (SELECT)		2		4

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

Автор		Сообщений
 kir0206	5
 pegoopik  	4
 gennadi_s  	2

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Продолжить чтение "Почему в Postgres нет synchronous_commit=remote_receive?"

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

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

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

§ Автор усилил проверку задачи 241 (SELECT, рейтинг) и поднял ее сложность до 2 баллов.

§ Под номером 242 опубликована новая задачи от gennadi_s (SELECT, рейтинг, сложность 2 балла).

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

Топик		Сообщений	Просмотров
 241 (SELECT)		11		4
 Guest's book		3		8
 134 (SELECT)		2		4

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

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

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

Автор: 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 дал ему повод снова стать важным, и к этому мы в итоге и придём.

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

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

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

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

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

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