SQL-Ex blog

Пересказ статьи Jamal Hansen. Optimizing Queries: EXPLAIN for Python Developers

Читайте вывод EXPLAIN для понимания того, почему запросы выполняются медленно. Узнайте, когда добавить индексы, а когда перестать беспокоиться о производительности.

По мере роста базы данных запросы начинают работать медленнее. Это ожидаемо.

Если ваши запросы постоянно выполняются медленно, сам запрос может быть проблемой.

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

Иногда медленный запрос означает, что вы не выбрали наиболее эффективный подход. А иногда ваши данные просто переросли тот способ, принимаемый базой данных по умолчанию, чтобы найти записи, и вам необходимо оказать ей небольшую помощь.

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

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

Поправка: в статье о max_connections я рекомендовал учитывать при расчёте этого параметра «подключения репликации». Начиная с PostgreSQL 12 так делать не нужно. Для процессов отправки WAL предусмотрены собственные места в отдельном пуле, размер которого задаётся этим параметром. С версии 12 они больше не используют места, выделенные параметром max_connections. Всё остальное в той статье остаётся верным: ошибочным было только это утверждение, причём для всех версий, которые вам следует использовать.

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

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

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

max_sync_workers_per_subscription определяет, сколько таблиц одна подписка копирует одновременно. Это не параметр, задающий скорость первоначального копирования, хотя именно для её увеличения многие и повышают его значение. Каждый рабочий процесс синхронизации таблиц копирует ровно одну таблицу — от начала до конца. Таким образом, параметр обеспечивает параллельную обработку разных таблиц, но никак не ускоряет копирование одной отдельной таблицы. Самая большая таблица будет копироваться одинаково долго независимо от того, установлено здесь значение 2, 8 или 200. А первоначальная синхронизация подписки не завершится раньше, чем закончится копирование этой таблицы.

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

Christophe Pettus: All Your GUCs in a Row: max_standby_archive_delay and max_standby_streaming_delay

max_standby_streaming_delay — это не ограничение времени выполнения запроса, какими бы ни казались его название и значение по умолчанию. Этот параметр задаёт величину отставания реплики, на которую вы готовы пойти ради выполнения запросов на резервном сервере. Когда отведённый запас исчерпан, отменяют именно запросы. max_standby_archive_delay выполняет ту же функцию для WAL, поступающего через restore_command, а не от процесса отправки WAL. Я буду рассматривать их как один параметр с двумя именами и объясню, зачем нужны оба.

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

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

Параметр max_slot_wal_keep_size определяет, кто погибнет, если реплика перестанет получать WAL: реплика или основной сервер. Значение по умолчанию выбирает основной сервер.

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

Пересказ статьи Mehdi Ghapanvari. SQL Server Table-Valued Parameter Join Issues in Stored Procedures

В статье Проблемы производительности при соединении временных таблиц SQL против табличных переменных я объяснял, почему следует избегать табличных переменных в операторах соединения. Проблема может стать более сложной, когда табличнозначный параметр используется в соединении в хранимой процедуре. Это происходит потому, что добавляется еще одна проблема, которая называется прослушиванием параметра (Parameter Sniffing). Если вас интересует, как решить эти проблемы, продолжайте читать, чтобы узнать больше.

Многие разработчики передают таблицу данных из приложения в хранимую процедуру. Затем они используют ее в операторе соединения (join) для фильтрации результатов. Хранимые процедуры могут получать эти данные как входной параметр при использовании табличнозначного параметра (TVP). Чтобы передать несколько строк при помощи TVP, вы должны определить пользовательский табличный тип данных. Вы можете больше узнать об этом в следующей статье.
Продолжить чтение "Проблемы соединений табличнозначного параметра в хранимых процедурах SQL Server"

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

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

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

	Участник		w_sel	all_sel	select	dml	Всего	Рейтинг
 Gitinomagomedov  (gmansur88)  	11	99	25	0	25	269
 Ш С. (junopark1)              	8	76	18	0	18	422
 Иванова О.Н.  (olga_ivanova)  	10	19	13	0	13	1667
 O  (janeoosql)                	4	36	10	0	10	1262
 Timonin D.E.  (DmiTim)        	3	70	5	0	5	531

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

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

max_replication_slots — это размер массива в общей памяти, и ничего больше. Этот параметр не определяет, кому разрешено создавать слоты, сколько WAL может удерживать слот и когда система должна очищать заброшенные слоты. Он задаёт количество элементов в массиве. Сам массив выделяется один раз при запуске сервера, поэтому единственная действительно важная особенность этого значения заключается в том, что изменить его без перезапуска невозможно.

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

Автор Gülçin Yıldırım Jelíenk: New system views in PostgreSQL 19

Работая над статьёй об улучшениях мониторинга в PostgreSQL 19 и готовя новый доклад о наблюдаемости PostgreSQL для конференции PostgreSQL Conference Europe, которая состоялась в октябре, я заметила, что в этом выпуске системным представлениям посвятили отдельный раздел. Последний раз им уделяли столь же заметное внимание в PostgreSQL 13 и 14. Поэтому я решила, что системные представления заслуживают отдельной статьи, в которой можно подробно разобрать все изменения.

Продолжить чтение "Новые системные представления в PostgreSQL 19"

Christophe Pettus: All Your GUCs in a Row: max_prepared_transactions

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

Параметр max_prepared_transactions определяет, сколько таких транзакций, существующих отдельно от своих сеансов, сервер может одновременно удерживать. Значение по умолчанию — 0, верхняя граница — 262143. Контекст настройки — postmaster, поэтому для включения этой возможности потребуется перезапуск сервера. Для её отключения перезапуск тоже необходим.

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

Christophe Pettus: All Your GUCs in a Row: max_pred_locks_per_transaction

У параметра max_pred_locks_per_transaction есть та же проблема с названием, что и у max_locks_per_transaction, а вдобавок и собственная особенность. Как и его тезка, он определяет размер таблицы, рассчитанный на каждый слот серверного процесса, а не ограничивает количество блокировок отдельной транзакции. Но, в отличие от своего тезки, большая часть записей в этой таблице в любой момент времени относится к транзакциям, которые уже завершились фиксацией.

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

Автор Christophe Pettus: All Your GUCs in a Row: max_pred_locks_per_page and max_pred_locks_per_relation

При использовании уровня изоляции SERIALIZABLE PostgreSQL должен запоминать, какие данные прочитала каждая транзакция. Для этого выделен определённый объём общей памяти, и он ограничен.

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

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

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

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

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

Пересказ статьи Lee Asher. What is fillfactor in PostgreSQL – and when should you adjust it

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

При установке PostgreSQL предварительно конфигурируются сотни различных настроек. Вам никогда не придется изменять (или даже знать) большинство из них, но есть одна, с которой вы определенно должны познакомиться: fillfactor. Продолжить чтение "Что такое fillfactor в PostgreSQL - и когда следует настраивать его?"

Christophe Pettus: Workers of the World, Unite! – PostgreSQL Background Worker Configuration

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

Продолжить чтение "Рабочие процессы всех стран, объединяйтесь!"