SQL-Ex blog

5 причин, которые следует рассмотреть при падении производительности запроса

nospam@example.com (Sergey Moiseenko) — Fri, 07 Oct 2022 16:14:00 +0300

Пересказ статьи Esat Erkec. 5 reasons to consider on your Query Performance degradation

Эта статья дает фундаментальные идеи относительно 5 причин, которые могут вызвать падение производительности запроса в SQL Server.

Введение

Человек, профессионально работающий с базами данных, может получить сообщение или звонок с жалобой на производительность запроса. Обычно это звучит так: "Мое приложение или отчет внезапно начало работать медленно, а вчера не было никаких проблем". Теперь давайте посмотрим, как подойти к решению таких проблем. На самом деле огромное число факторов могут привести в деградации производительности запроса. Например, мы можем перечислить следующие причины, которые первыми приходят на ум:
Continue reading "5 причин, которые следует рассмотреть при падении производительности запроса"

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

nospam@example.com (mssqlhelp) — Wed, 07 Oct 2026 20:25:00 +0300

Christophe Pettus: All Your GUCs in a Row: local_preload_libraries

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

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

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

nospam@example.com (mssqlhelp) — Thu, 06 Aug 2026 21:23:00 +0300

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

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

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

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

nospam@example.com (mssqlhelp) — Wed, 07 Oct 2026 09:48:00 +0300

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

lock_timeout — это параметр безопасности миграций схемы, который, кстати, применяется ко всем блокировкам в системе. Он ограничивает, как долго оператор будет ждать получения любой отдельной «тяжёлой» блокировки, прежде чем сдаться с ошибкой ERROR: canceling statement due to lock timeout (SQLSTATE 55P03, тот же код, что и у сбоев NOWAIT, что удобно для клиентского кода). Значение по умолчанию — 0, что означает «отключено». Контекст — пользовательский. Миллисекунды, если вы не указали единицы измерения. Он появился в 9.3, и то, что он дождался 2013 года, говорит вам о том, как долго люди жили с проблемой, которую он решает.

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

Всё о GUC по порядку: krb_caseins_users и krb_server_keyfile

nospam@example.com (mssqlhelp) — Tue, 06 Oct 2026 13:28:00 +0300

Автор Christophe Pettus: All Your GUCs in a Row: krb_caseins_users and krb_server_keyfile

Ни один из этих параметров не имеет никакого отношения к методу аутентификации krb5, поскольку PostgreSQL удалил этот метод в версии 9.4. Приставка krb_ сохраняется по той обычной причине, по которой имена параметров переживают всё: переименование GUC ломает каждый postgresql.conf, который его упоминает. На самом деле они настраивают аутентификацию GSSAPI — метод gss в pg_hba.conf, который означает Kerberos, а на практике это обычно означает Active Directory (их «собратьям повезло меньше: krb_server_hostname ушёл в 8.4, а krb_srvname пошёл ко дну вместе с кораблём в 9.4).

Большая часть политики GSSAPI живёт в pg_hba.conf, построчно: include_realm, krb_realm, map. Эти две настройки являются общесерверными, поэтому они вообще являются GUC. Обе имеют контекст sighup; перезагрузки конфигурации достаточно, перезапуск не нужен.

Continue reading "Всё о GUC по порядку: krb_caseins_users и krb_server_keyfile"

Отказоустойчивость PostgreSQL на Kubernetes за 10 минут

nospam@example.com (mssqlhelp) — Tue, 06 Oct 2026 13:15:00 +0300

Автор Hans-Juergen Schoenig: Highly Available PostgreSQL on Kubernetes in 10 Minutes

«Отказоустойчивый PostgreSQL» обычно означает выборы лидера, потоковые реплики, автоматическое переключение при сбое, проверки работоспособности и массу тщательного связывания. С оператором CYBERTEC PG Operator (CPO) это означает YAML-файл из 14 строк. Вот он целиком, от начала до конца, на ноутбуке с minikube.

Каждая команда и каждый вывод ниже взяты из учебного руководства, которое мы выполнили от начала до конца на свежем minikube (Kubernetes 1.30, CPO 0.9.2, PostgreSQL 18.4).

Continue reading "Отказоустойчивость PostgreSQL на Kubernetes за 10 минут"

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

nospam@example.com (mssqlhelp) — Tue, 06 Oct 2026 12:48:00 +0300

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

PostgreSQL, как известно, не реализует подсказки к запросам. Это примерно на 95% правда, и join_collapse_limit — это те самые оставшиеся 5%: установите его в 1, и планировщик соединит ваши таблицы ровно в том порядке, в котором вы их написали. Это не эксплойт и не случайность реализации; это задокументировано, и, по словам Тома Лейна (Tom Lane) в списке pgsql-hackers, это по сути причина, по которой параметр всё ещё существует. Проект годами говорил людям, что они могут навязать порядок соединений, написав явное вложение JOIN, и удаление этого аварийного люка показалось плохой идеей. Так что у PostgreSQL есть ровно одна подсказка порядка соединений. Просто она не пишется как подсказка.

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

Всё о GUC по порядку: jit и jit_provider

nospam@example.com (mssqlhelp) — Sun, 04 Oct 2026 14:40:00 +0300

Автор Christophe Pettus: All Your GUCs in a Row: jit and jit_provider

Мы приступили к массиву к семейства jit_*, и здесь алфавит перестаёт быть полезным редактором. Строгий порядок поставил бы пороговые значения стоимости перед концепциями, которые они ограничивают, и оставил бы jit_provider в одиночестве на дальнем конце, поэтому для этого семейства мы идём логическими кластерами: сегодня переключатель и движок, затем пара, решающая, что компилируется, затем три порога стоимости, а отладочные переключатели — в конце.

Continue reading "Всё о GUC по порядку: jit и jit_provider"

Всё о GUC по порядку: jit_debugging_support, jit_dump_bitcode и jit_profiling_support

nospam@example.com (mssqlhelp) — Mon, 05 Oct 2026 20:39:00 +0300

Автор Christophe Pettus: All Your GUCs in a Row: jit_debugging_support, jit_dump_bitcode, and jit_profiling_support

Семейство jit_* закрывается тремя параметрами для тех, кто работает над самим JIT, а не с ним. Все три — логические, все по умолчанию выключены, все восходят к исходной работе над PostgreSQL 11 и все живут в разделе «Параметры разработчика». Что делает их достойными поста, так это то, что один из них действительно интересен, а два других демонстрируют контекст GUC, которого эта серия ещё не встречала.

Continue reading "Всё о GUC по порядку: jit_debugging_support, jit_dump_bitcode и jit_profiling_support"

Всё о GUC по порядку: jit_above_cost, jit_inline_above_cost и jit_optimize_above_cost

nospam@example.com (mssqlhelp) — Mon, 05 Oct 2026 17:46:00 +0300

Автор Christophe Pettus: All Your GUCs in a Row: jit_above_cost, jit_inline_above_cost, and jit_optimize_above_cost

Третий блок семейства jit_* — тот, который решает, когда JIT срабатывает, и именно здесь живут неприятности. Все три появились вместе с подсистемой в PostgreSQL 11, у всех трёх контекст — пользовательский, и все три выражены в единицах стоимости планировщика — той безразмерной валюте, привязанной к seq_page_cost = 1.0. Когда планировщик завершает план, он сравнивает общую оценочную стоимость плана с этими порогами и запечатывает результат в сам план. Стоимость выше jit_above_cost (по умолчанию 100000): компилировать выражения и деформирование кортежей. Выше jit_inline_above_cost (по умолчанию 500000): также встраивать тела встроенных функций и операторов, извлекаемые из биткода LLVM, установленного вместе с сервером. Выше jit_optimize_above_cost (тоже 500000): также прогонять дорогостоящие проходы оптимизации LLVM по результату. Установка любого из них в -1 отключает этот уровень; jit_above_cost = -1 отключает всю затею, поскольку два других уровня надстраиваются над первым.

Continue reading "Всё о GUC по порядку: jit_above_cost, jit_inline_above_cost и jit_optimize_above_cost"

Тригонометрические функции T-SQL в SQL Server

nospam@example.com (Sergey Moiseenko) — Sun, 04 Oct 2026 20:26:00 +0300

Пересказ статьи Imran2629. T-SQL Trigonometric Functions in SQL Server

Введение

SQL Server содержит несколько встроенных математических функций, которые позволяют разработчикам выполнять сложные вычисления непосредственно в запросах. Среди них имеются такие тригонометрические функции, как SIN(), COS() и TAN(), полезные в сценариях, которые включают инженерные расчеты, обработку географических данных, моделирование и аналитику.

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

В этой статье рассматриваются несколько практических примеров, демонстрирующих поведение тригонометрических вычислений в SQL Server. Мы также исследуем несколько распространенных ошибок и покажем, как небольшие изменения, такие как выбор правильного типа данных или результаты округления, помогут избежать сбивающего с толку вывода. Continue reading "Тригонометрические функции T-SQL в SQL Server"

Синхронизация слотов PostgreSQL после переключения при сбое

nospam@example.com (mssqlhelp) — Sun, 04 Oct 2026 20:25:00 +0300

Автор Ajin Cherian: Failover slot synchronization in PostgreSQL

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

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

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

Continue reading "Синхронизация слотов PostgreSQL после переключения при сбое"

Всё о GUC по порядку: jit_expressions и jit_tuple_deforming

nospam@example.com (mssqlhelp) — Sun, 04 Oct 2026 14:35:00 +0300

Автор Christophe Pettus: All Your GUCs in a Row: jit_expressions and jit_tuple_deforming

Продолжая проходить семейство jit_* в логических кластерах: эта пара решает, что именно компилирует JIT, и вы уже видели их имена, потому что это те самые «Expressions true, Deforming true», напечатанные в каждом блоке JIT, который показывал прошлый пост. Оба — логические, контекст — пользовательский, по умолчанию включены, часть исходной работы над JIT в PostgreSQL 11, и помещены в раздел «Параметры разработчика» — раздел документации, который идёт с постоянным предупреждением «не для производственной базы данных».

Continue reading "Всё о GUC по порядку: jit_expressions и jit_tuple_deforming"

Всё о GUC по порядку: io_method и io_workers

nospam@example.com (mssqlhelp) — Sat, 03 Oct 2026 11:26:00 +0300

Christophe Pettus: All Your GUCs in a Row: io_method and io_workers

Параметры io_*, которые мы рассматривали до сих пор, описывают сами запросы ввода-вывода: насколько велик каждый из них, сколько процесс может держать в полёте. Эти два решают, кто фактически их выполняет. Я писал об архитектуре и о том, что PostgreSQL 19 с ней делает, в статье AIO Grows Up; здесь — взгляд на уровне параметров, и он включает исправление того, что я там сказал.

Continue reading "Всё о GUC по порядку: io_method и io_workers"

Новости за 2026-09-26 - 2026-10-02

nospam@example.com (Sergey Moiseenko) — Fri, 02 Oct 2026 19:28:00 +0300

§ Рейтинговая задача 254 от Baser перенесена на обучающий этап под номером 168 (сложность 3 балла).

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

Топик		Сообщений	Просмотров
 53 (SELECT)		12		6
 303 (SELECT)		6		3

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

Автор		Сообщений
 pegoopik  	8
 selber  	4
 gennadi_s  	2
 vasilyvanc  	2

Continue reading "Новости за 2026-09-26 - 2026-10-02"

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

nospam@example.com (mssqlhelp) — Fri, 02 Oct 2026 14:35:00 +0300

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

effective_io_concurrency — это запрос. io_max_concurrency — это удовлетворение.

Новый в PostgreSQL 18 как часть подсистемы асинхронного ввода-вывода, io_max_concurrency представляет собой жёсткий потолок того, сколько операций ввода-вывода один процесс может иметь в полёте одновременно. Не на весь кластер; на процесс. Контекст — postmaster, поэтому для изменения требуется перезапуск, а значение по умолчанию — -1, что указывает PostgreSQL выбрать значение при запуске. Диапазон простирается до 1024.

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

PostgreSQL умер и устаревшее соединение: как их отличить

nospam@example.com (mssqlhelp) — Thu, 01 Oct 2026 09:26:00 +0300

Автор Umair Shahid: PostgreSQL Lockup vs Stale Connection: How to Tell Them Apart

«База данных зависла». Мы слышали ту или иную версию этого предложения не раз за прошедшую неделю, от одной и той же команды, по поводу того, что выглядело как одна и та же проблема. Это была не одна и та же проблема. Однажды Postgres действительно перестал отвечать. Все остальные разы Postgres был в порядке, а соединение, находившееся в пуле приложения, тихо умерло где-то между приложением и базой данных.

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

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

Continue reading "PostgreSQL умер и устаревшее соединение: как их отличить"

Всё о GUC по порядку: io_combine_limit и io_max_combine_limit

nospam@example.com (mssqlhelp) — Wed, 30 Sep 2026 18:01:00 +0300

Автор Christophe Pettus: All Your GUCs in a Row: io_combine_limit and io_max_combine_limit

Теперь мы вступаем во владения io_* — самую новую в пространстве имён GUC: ничего из этого не существовало до PostgreSQL 17. Если effective_io_concurrency отвечает на вопрос «сколько операций ввода-вывода мы держим в полёте?», то io_combine_limit отвечает на ортогональный вопрос: «какова величина каждой из них?» Глубина и ширина.

Continue reading "Всё о GUC по порядку: io_combine_limit и io_max_combine_limit"

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

nospam@example.com (mssqlhelp) — Tue, 29 Sep 2026 18:01:00 +0300

Автор Christophe Pettus: https://thebuild.com/blog/all-your-gucs-in-a-row-intervalstyle/

IntervalStyle — младший «брат» DateStyle, и он унаследовал семейную черту: он выглядит как предпочтение форматирования вывода, но также меняет то, как PostgreSQL разбирает ваш ввод. Мы рассматривали версию даты этого трюка в статье про DateStyle. Версия для интервалов менее известна и в одном конкретном случае более неприятна.

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

Транзакции в PostgreSQL: COMMIT, ROLLBACK и SAVEPOINT

nospam@example.com (Sergey Moiseenko) — Tue, 29 Sep 2026 16:50:00 +0300

Пересказ статьи PostgreSQL Transactions: COMMIT, ROLLBACK and SAVEPOINT

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

Но что если в середине произойдет сбой?

Вот почему PostgreSQL использует транзакции - для гарантии, что ваши данные останутся корректными.
Continue reading "Транзакции в PostgreSQL: COMMIT, ROLLBACK и SAVEPOINT"

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

nospam@example.com (mssqlhelp) — Mon, 28 Sep 2026 12:27:00 +0300

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

Каждое соединение, которое кто-либо устанавливал с сервером PostgreSQL начиная с версии 8.0, открывалось с того, что сервер без приглашения объявлял значение integer_datetimes. Начиная с PostgreSQL 10 объявляемое значение — это единственное значение, с которым вообще может быть собран сервер PostgreSQL, и текущая документация отделывается от всей темы одним предложением: «Начиная с PostgreSQL 10 это всегда on». Так что это пост о том, почему параметр ровно с одним возможным значением всё ещё представляется каждому клиенту в начале каждого разговора.

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

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

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

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

in_hot_standby — это лампочка, а не переключатель. Он сообщает, является ли сервер, к которому вы подключены, в данный момент горячим резервом: включён, когда ваша сессия работает на реплике, которая воспроизводит WAL и принимает запросы только для чтения (состояние, которое включает hot_standby), выключен на первичном сервере. Это логический параметр, он появился в PostgreSQL 14, и его контекст — ни один из обычных четырёх, потому что никто не может его изменить:

postgres=# SET in_hot_standby = off;

ERROR:  parameter "in_hot_standby" cannot be changed

postgres=# ALTER SYSTEM SET in_hot_standby = off;

ERROR:  parameter "in_hot_standby" cannot be changed

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

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

nospam@example.com (mssqlhelp) — Fri, 25 Sep 2026 23:18:00 +0300

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

ignore_system_indexes завершает череду из трёх последовательных параметров с именем ignore_-что-то и с удобным отрывом является самым вежливым в этом семействе. ignore_checksum_failure и ignore_invalid_pages говорят PostgreSQL продолжать, несмотря на доказательства повреждения; этот же просто говорит ему перестать доверять набору путей доступа. Это логический параметр, по умолчанию выключен, и он живёт в редком контексте backend: его можно установить только до того, как сессия существует, либо в postgresql.conf (влияя только на новые сессии), либо во время подключения, что удобнее всего сделать как PGOPTIONS="-P", эквивалентный серверный переключатель. Установите его после подключения — и получите ошибку. Во всех поддерживаемых версиях это один из ровно двух параметров с таким контекстом (другой — post_auth_delay), он классифицирован как параметр разработчика и не появляется в образце файла конфигурации. Всё это — способ сервера сказать: вы не должны были это находить.

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

Новости за 2026-09-19 - 2026-09-25

nospam@example.com (Sergey Moiseenko) — Fri, 25 Sep 2026 18:58:00 +0300

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

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

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

Рейтинг	 Участник (решенные задачи, время в днях)
 140		Rujan (143, 453.871)
 316		saah (109, 48.785)

Continue reading "Новости за 2026-09-19 - 2026-09-25"

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

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

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

Никто не находит ignore_invalid_pages, читая документацию от корки до корки. Вы находите его, вставив PANIC: WAL contains references to invalid pages в поисковую систему, обычно в час, когда вы предпочли бы спать. Это параметр разработчика, отсутствующий в postgresql.conf.sample, присутствующий начиная с PostgreSQL 13. По умолчанию он выключен, а контекст — postmaster, что на этот раз ничего не стоит: сервер, который вам нужно было бы перезапустить, уже не работает.

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

Первая нормальная форма (1NF): нарушение "ненарушаемого правила" в проектировании базы данных

nospam@example.com (Sergey Moiseenko) — Wed, 23 Sep 2026 20:18:00 +0300

Пересказ статьи Lee Asher. First Normal Form (1NF): Breaking the ‘unbreakable rule’ in database design

Первая нормальная форма (1NF) является самым известным правилом в нормализации базы данных. Оно требует, чтобы таблицы не содержали повторяющихся групп и каждый столбец содержал атомарные значения. Но в реальных системах баз данных разработчики часто намеренно нарушают это правило при моделировании сложных данных. Давайте выясним почему.

Правильная нормализация данных является критической проблемой при проектировании базы данных, контролируемой набором правил моделирования данных, известных как "нормальные формы". Хотя даже лучшие разработчики затрудняются в объяснении различия между более высокими нормальными формами, одно правило, которое мы все знаем, это Первая Нормальная Форма. Обычно ее называют 1НФ, а правило часто выражают просто тремя словами: нет повторяющихся групп.
Continue reading "Первая нормальная форма (1NF): нарушение "ненарушаемого правила" в проектировании базы данных"

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

nospam@example.com (mssqlhelp) — Wed, 23 Sep 2026 18:21:00 +0300

Christophe Pettus: All Your GUCs in a Row: ignore_checksum_failure

ignore_checksum_failure — это не столько параметр конфигурации, сколько ломик в витрине за стеклом. По умолчанию он выключен, он вообще не появляется в postgresql.conf.sample (образец файла вежливо отказывается его рекламировать), и документация помещает его в раздел «Параметры разработчика», рядом с другими инструментами, которые вы надеетесь никогда не будете держать в руках. Контекст — суперпользователь, что означает, что суперпользователь (или роль, которой было предоставлено право SET на него, а такой роли не должно существовать) может переключить его в живой сессии командой SET; без перезагрузки, без перезапуска. Именно такая гранулярность и требуется для его единственного законного применения. Он появился в PostgreSQL 9.3 вместе с самими контрольными суммами данных: функция, которая проверяет, и рычаг, который отменяет проверку, родились вместе.

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

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

nospam@example.com (mssqlhelp) — Tue, 22 Sep 2026 14:33:00 +0300

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

idle_session_timeout — это уборка, а не защита. Его «собрат», idle_in_transaction_session_timeout, защищает базу данных от реального вреда: простаивающая транзакция удерживает блокировки и фиксирует горизонт xmin, и vacuum от этого страдает. Сессия, простаивающая вне транзакции, ничего из этого не делает. Она занимает слот соединения, фоновый процесс и немного памяти. Вот и весь счёт, и этот параметр существует, чтобы его выставить. В документации сказано то же самое, отмечая, что простаивающая сессия без транзакции не создаёт больших затрат, поэтому необходимости в этом таймауте меньше, чем в его «собрате».

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

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

nospam@example.com (mssqlhelp) — Mon, 21 Sep 2026 17:43:00 +0300

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

idle_replication_slot_timeout делит алфавитное соседство с idle_in_transaction_session_timeout и idle_session_timeout, но решает противоположную проблему. Те отключают клиентов, которые остаются слишком долго. Этот же, новый в PostgreSQL 18, имеет дело с клиентами, которые вообще перестают появляться: он ставит срок годности на слоты репликации.

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

За пределами VARBINARY: как сохранить PDF в SQL Server, используя FILESTREAM и FileTable

nospam@example.com (Sergey Moiseenko) — Mon, 21 Sep 2026 11:32:00 +0300

Пересказ статьи gbargsley. Beyond VARBINARY: How to Store PDFs in SQL Server Using FILESTREAM and FileTable

Сегодня мы поговорим о теме, которая возникает чаще, чем вы думаете: хранение PDF-документов внутри SQL Server.

Будут ли это счета, отчеты, отсканированные формы или контракты, приложениям часто нужно где-то хранить файлы. Вы могли бы хранить их в общей сетевой папке и надеяться, что ничто не повредит ссылку, или вы можете полностью перенести их в SQL Server, где они будут находиться вместе с вашими данными. В этой статье я собираюсь рассказать вам о настройке FILESTREAM и FileTable в SQL Server, средствах, которые дают вам лучшее из двух миров: транзакционная целостность от SQL Server и производительность файловой системы от NTFS. Continue reading "За пределами VARBINARY: как сохранить PDF в SQL Server, используя FILESTREAM и FileTable"

Новости за 2026-09-12 - 2026-09-18

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

§ Выполнена следующая цепочка переносов:
53 -> 11 -> 3 -> обучающий (167).
Второй этап начинается теперь с задачи №3.
Под номером 53 опубликована новая задача от pegoopik (сложность 3 балла).
Актуализируйте свой сертификат!

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

Топик		Сообщений	Просмотров
 54 (Learn)		3		6
 58 (Learn)		2		7
 Guest's book		2		8

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

Автор		Сообщений
 Nividimka	2
 selber  	2
 gennadi_s  	2

Continue reading "Новости за 2026-09-12 - 2026-09-18"

Граница вашей транзакции принадлежит программе, а не имени файла

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

Alexey Evlampiev: Your Transaction Boundary Belongs in the Program, Not the Filename

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

Continue reading "Граница вашей транзакции принадлежит программе, а не имени файла"

ALTER TABLE выполняется быстро. Очередь за ним — нет

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 "ALTER TABLE выполняется быстро. Очередь за ним — нет"

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

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

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

idle_in_transaction_session_timeout существует потому, что на код приложения нельзя положиться в том, что он доведёт до конца то, что начал. ORM открывает транзакцию, исключение уводит выполнение по неожиданному пути, соединение возвращается в пул с всё ещё открытой транзакцией, и теперь у PostgreSQL есть сессия, которая будет удерживать всё, к чему прикоснулась, пока кто-нибудь это не заметит. Этот параметр и есть тот самый «кто-нибудь».

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

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

nospam@example.com (mssqlhelp) — Thu, 17 Sep 2026 17:05:00 +0300

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

ident_file сообщает серверу, где находится pg_ident.conf. Вот и вся функция. Интересная часть — это то, что происходит, когда он указан неправильно, а именно: ничего, громко, в журнале, который никто не читает.

Значение по умолчанию — pg_ident.conf в каталоге конфигурации, то есть в каталоге, содержащем postgresql.conf, а не обязательно в каталоге данных. Контекст — postmaster, поэтому для изменения требуется перезапуск, и он несёт флаг «только для суперпользователя», поэтому непривилегированная роль, запрашивающая SHOW ident_file, получает ошибку прав доступа вместо ответа. Относительный путь разрешается относительно рабочего каталога того, кто запустил postgres, а не относительно PGDATA.

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

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

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