Семейство jit_* закрывается тремя параметрами для тех, кто работает над самим JIT, а не с ним. Все три — логические, все по умолчанию выключены, все восходят к исходной работе над PostgreSQL 11 и все живут в разделе «Параметры разработчика». Что делает их достойными поста, так это то, что один из них действительно интересен, а два других демонстрируют контекст GUC, которого эта серия ещё не встречала.
Третий блок семейства 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 отключает всю затею, поскольку два других уровня надстраиваются над первым.
SQL Server содержит несколько встроенных математических функций, которые позволяют разработчикам выполнять сложные вычисления непосредственно в запросах. Среди них имеются такие тригонометрические функции, как SIN(), COS() и TAN(), полезные в сценариях, которые включают инженерные расчеты, обработку географических данных, моделирование и аналитику.
Хотя эти функции довольно просты в использовании, разработчики время от времени сталкиваются с неожиданными результатами при работе с углами и тригонометрическими вычислениями. Во многих случаях проблема связана не с самой функцией, а с тем, как SQL Server выполняет преобразование типов данных, и с точностью вычислений с плавающей запятой.
В этой статье рассматриваются несколько практических примеров, демонстрирующих поведение тригонометрических вычислений в SQL Server. Мы также исследуем несколько распространенных ошибок и покажем, как небольшие изменения, такие как выбор правильного типа данных или результаты округления, помогут избежать сбивающего с толку вывода.
Продолжить чтение "Тригонометрические функции T-SQL в SQL Server"
Высокая доступность критически важна для сред логической репликации, но до недавнего времени переключение при сбое всё ещё могло оставлять подписчиков отключёнными от слотов репликации, от которых они зависят. PostgreSQL 17 решил это, представив синхронизацию слотов при переключении при сбое, что позволяет держать слоты логической репликации готовыми на резервных серверах и снижает потребность в полной пересинхронизации подписчиков после повышения.
PostgreSQL 19 развивает эту основу с помощью повторно-осведомлённой ручной синхронизации и более ясной видимости пропущенных попыток синхронизации слотов. В этой статье мы рассмотрим, как работают эти возможности и как вклад команды разработчиков PostgreSQL из Fujitsu помогает сделать переключение при сбое логической репликации более надёжным и простым в эксплуатации.
Узнайте, как PostgreSQL улучшает синхронизацию слотов при переключении при сбое для логической репликации, повышая надёжность и сокращая время простоя при переключениях.
Мы приступили к массиву к семейства jit_*, и здесь алфавит перестаёт быть полезным редактором. Строгий порядок поставил бы пороговые значения стоимости перед концепциями, которые они ограничивают, и оставил бы jit_provider в одиночестве на дальнем конце, поэтому для этого семейства мы идём логическими кластерами: сегодня переключатель и движок, затем пара, решающая, что компилируется, затем три порога стоимости, а отладочные переключатели — в конце.
Продолжая проходить семейство jit_* в логических кластерах: эта пара решает, что именно компилирует JIT, и вы уже видели их имена, потому что это те самые «Expressions true, Deforming true», напечатанные в каждом блоке JIT, который показывал прошлый пост. Оба — логические, контекст — пользовательский, по умолчанию включены, часть исходной работы над JIT в PostgreSQL 11, и помещены в раздел «Параметры разработчика» — раздел документации, который идёт с постоянным предупреждением «не для производственной базы данных».
Параметры io_*, которые мы рассматривали до сих пор, описывают сами запросы ввода-вывода: насколько велик каждый из них, сколько процесс может держать в полёте. Эти два решают, кто фактически их выполняет. Я писал об архитектуре и о том, что PostgreSQL 19 с ней делает, в статье AIO Grows Up; здесь — взгляд на уровне параметров, и он включает исправление того, что я там сказал.
effective_io_concurrency — это запрос. io_max_concurrency — это удовлетворение.
Новый в PostgreSQL 18 как часть подсистемы асинхронного ввода-вывода, io_max_concurrency представляет собой жёсткий потолок того, сколько операций ввода-вывода один процесс может иметь в полёте одновременно. Не на весь кластер; на процесс. Контекст — postmaster, поэтому для изменения требуется перезапуск, а значение по умолчанию — -1, что указывает PostgreSQL выбрать значение при запуске. Диапазон простирается до 1024.
«База данных зависла». Мы слышали ту или иную версию этого предложения не раз за прошедшую неделю, от одной и той же команды, по поводу того, что выглядело как одна и та же проблема. Это была не одна и та же проблема. Однажды Postgres действительно перестал отвечать. Все остальные разы Postgres был в порядке, а соединение, находившееся в пуле приложения, тихо умерло где-то между приложением и базой данных.
Обе неисправности приводят к одному и тому же вызову в 2 часа ночи: приложение не может связаться с базой данных. Только одна из них означает, что база данных действительно в беде. Путаница между ними стоит вам самого дорогого ресурса в инциденте — первых десяти минут, когда вы ещё решаете, с каким типом проблемы имеете дело.
Истинное зависание PostgreSQL означает, что сам сервер перестал отвечать на уровне операционной системы. Вы не можете открыть новую сессию к нему, ни с какого клиента, ниоткуда. Проблема устаревшего соединения означает, что Postgres здоров и доступен. Проблема в конкретном соединении, уже находящемся в пуле вашего приложения, которое указывает на сокет, умерший где-то по пути, обычно без того, чтобы какая-либо из сторон получила чистый сигнал о том, что это произошло.
Теперь мы вступаем во владения io_* — самую новую в пространстве имён GUC: ничего из этого не существовало до PostgreSQL 17. Если effective_io_concurrency отвечает на вопрос «сколько операций ввода-вывода мы держим в полёте?», то io_combine_limit отвечает на ортогональный вопрос: «какова величина каждой из них?» Глубина и ширина.
Автор Christophe Pettus: https://thebuild.com/blog/all-your-gucs-in-a-row-intervalstyle/
IntervalStyle — младший «брат» DateStyle, и он унаследовал семейную черту: он выглядит как предпочтение форматирования вывода, но также меняет то, как PostgreSQL разбирает ваш ввод. Мы рассматривали версию даты этого трюка в статье про DateStyle. Версия для интервалов менее известна и в одном конкретном случае более неприятна.
Когда вы работаете с базой данных, то часто выполняете несколько запросов, которые связаны друг с другом. Например, перемещение денег с одного счета на другой.
Каждое соединение, которое кто-либо устанавливал с сервером PostgreSQL начиная с версии 8.0, открывалось с того, что сервер без приглашения объявлял значение integer_datetimes. Начиная с PostgreSQL 10 объявляемое значение — это единственное значение, с которым вообще может быть собран сервер PostgreSQL, и текущая документация отделывается от всей темы одним предложением: «Начиная с PostgreSQL 10 это всегда on». Так что это пост о том, почему параметр ровно с одним возможным значением всё ещё представляется каждому клиенту в начале каждого разговора.
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
