SQL-Ex blog - Articles

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

nospam@example.com (mssqlhelp) — Wed, 19 Aug 2026 17:53:00 +0300

Christophe Pettus, All Your GUCs in a Row: enable_presorted_aggregate

enable_presorted_aggregate включён, он включён с момента появления в PostgreSQL 16, и самое полезное, что вы когда-либо сделаете с ним, — это отключите его ровно для одного запроса.

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

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

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

nospam@example.com (mssqlhelp) — Tue, 18 Aug 2026 14:45:00 +0300

Christophe Pettus, All Your GUCs in a Row: enable_partitionwise_join

«Собрат» параметра enable_partitionwise_aggregate, и он разделяет его определяющую черту: по умолчанию он выключен, и по той же причине. Поэтому, чтобы не повторять полностью аргументацию о том, почему он выключен по умолчанию, в этом посте рассматривается, что здесь отличается — механизм, преимущество, которого нет у версии для агрегации, и предусловие, достаточно строгое, чтобы быть главной причиной, по которой функция не срабатывает, когда люди её ожидают. По умолчанию выключен, контекст — пользовательский. Как и его «собрат», включение этого параметра — это реальное решение по настройке, а не диагностический зонд.

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

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

nospam@example.com (mssqlhelp) — Mon, 17 Aug 2026 16:04:00 +0300

Christophe Pettus, All Your GUCs in a Row: enable_partition_pruning

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

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

Как узнать последнее значение, используемое последовательностью в SQL Server

nospam@example.com (Sergey Moiseenko) — Sun, 16 Aug 2026 18:30:00 +0300

Пересказ статьи Greg Low. How to determine the last value used by a sequence in SQL Server

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

Что такое последовательности в SQL Server?

Последовательности позволяют создавать привязанный к схеме объект, который не связан ни с какой конкретной таблицей.

Например, если у меня есть таблицы Sales.FlightBookings и Sales.VehicleBookings, и я хочу иметь общий BookingID, используемый как ключ для каждой таблицы. Если бы речь шла не только о BookingID, вы могли бы возразить, что существует проблема с нормализацией таблиц, но мы оставим это обсуждение на будущее. Continue reading "Как узнать последнее значение, используемое последовательностью в SQL Server"

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

nospam@example.com (mssqlhelp) — Sun, 16 Aug 2026 11:49:00 +0300

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

Оптимизация для секционирования и примечательное исключение в семействе enable_*: по умолчанию она выключена. Почти все остальные члены семейства по умолчанию включены и существуют для того, чтобы вы могли отключить возможность для диагностики; этот же по умолчанию выключен и существует для того, чтобы вы могли включить его, когда решите, что оно стоит затрат. Это обратное поведение — и стоимость, которая его мотивирует, — составляют суть данного поста. Контекст — пользовательский. И в отличие от большинства членов семейства, изменение этого параметра — это легитимное решение по настройке, а не просто диагностический зонд.

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

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

nospam@example.com (mssqlhelp) — Sun, 16 Aug 2026 12:03:00 +0300

Christophe Pettus, All Your GUCs in a Row: enable_parallel_hash

Переключатель для параллельных запросов, уточняющий хэш-соединение из статьи про enable_hashjoin, и он требует точности, потому что «хэш-соединение, выполняемое параллельно» и «параллельное хэш-соединение» — это две действительно разные вещи. По умолчанию включён, контекст пользовательский, и он относится к тому же семейству, что и enable_async_append: это диагностический инструмент, а не регулятор настройки.

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

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

nospam@example.com (mssqlhelp) — Sat, 15 Aug 2026 14:09:00 +0300

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

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

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

Слишком много таблиц — это плохо

nospam@example.com (mssqlhelp) — Sat, 15 Aug 2026 13:45:00 +0300

Автор: Laurenz Albe, Too many tables are bad for you

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

Continue reading "Слишком много таблиц — это плохо"

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

nospam@example.com (mssqlhelp) — Thu, 13 Aug 2026 18:55:00 +0300

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

Последний из трёх переключателей стратегий соединения и в некотором смысле самый важный, потому что вложенный цикл (nested loop) — это одновременно и простейшее соединение в PostgreSQL, и источник самого печально известного катастрофического падения производительности. Три алгоритма были представлены в статье про enable_hashjoin; этот пост завершает серию. По умолчанию включён, контекст — пользовательский, и он относится к тому же семейству, что и enable_async_append: это диагностический инструмент, а не регулятор настройки.

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

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

nospam@example.com (mssqlhelp) — Wed, 12 Aug 2026 17:18:00 +0300

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

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

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

Обновление кластеров PostgreSQL 19 стало ещё более бесшовным

nospam@example.com (mssqlhelp) — Tue, 11 Aug 2026 17:38:00 +0300

Автор: Vigneshwaran C , Closing a critical gap in PostgreSQL upgrade workflows with sequence synchronization

Обновление кластеров PostgreSQL 19 стало более плавным благодаря таким инструментам, как pg_upgrade и pg_createsubscriber, которые вместе обеспечивают обновление с практически нулевым временем простоя, сначала преобразуя физические реплики в логических подписчиков, а затем выполняя обновление с минимальным прерыванием обслуживания.

Однако этот подход обнажает давний пробел в логической репликации: состояние последовательностей (sequence state) не реплицируется.

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

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

Continue reading "Обновление кластеров PostgreSQL 19 стало ещё более бесшовным"

Всё о GUC по порядку: enable_material и enable_memoize

nospam@example.com (mssqlhelp) — Tue, 11 Aug 2026 11:42:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: enable_material and enable_memoize

Два переключателя enable_* для двух узлов плана, которые оба, условно говоря, кешируют строки, чтобы избежать повторных вычислений, — именно поэтому их путают, и именно поэтому их стоит рассматривать вместе. Они не являются вариациями одной идеи. Materialize — это «тупой» буфер; Memoize — это «умный» кеш. Суть этого поста — чётко зафиксировать это различие. Оба параметра включены по умолчанию, оба относятся к пользовательскому контексту, и оба находятся в том же семействе, что и enable_async_append: это диагностические инструменты, а не регуляторы настройки производительности.

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

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

nospam@example.com (mssqlhelp) — Mon, 10 Aug 2026 13:51:00 +0300

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

Третий способ использования индекса, после обычного индексного сканирования и сканирования битовой карты из enable_indexscan и enable_bitmapscan, — и тот, у которого есть наиболее неправильно понимаемый «подвох», потому что сканирование только по индексу может быть физически возможным, но всё равно заканчиваться чтением кучи почти для каждой строки. Почему это происходит, и есть суть этого поста. По умолчанию включён, контекст — user, с тем же обрамлением семейства, что и у enable_async_append: диагностический инструмент, а не регулировочная ручка.

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

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

nospam@example.com (mssqlhelp) — Fri, 07 Aug 2026 11:57:00 +0300

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

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

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

pg_stats: как работает внутренняя статистика Postgres

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

Автор: Richard Yen, pg_stats: How Postgres Internal Stats Work

Недавно мне выпала честь выступить на POSETTE 2026 с докладом о pg_stats и о том, как работает внутренняя статистика Postgres (запись на YouTube). Эта статья является письменным дополнением к тому докладу и предназначен для того, чтобы дать вам рабочее понимание того, что такое pg_stats, как он заполняется и как он влияет на решения, которые планировщик запросов принимает от вашего имени.

Continue reading "pg_stats: как работает внутренняя статистика Postgres"

Всё о 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 по порядку: enable_gathermerge

nospam@example.com (mssqlhelp) — Tue, 04 Aug 2026 18:03:00 +0300

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

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

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

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

nospam@example.com (mssqlhelp) — Tue, 04 Aug 2026 13:57:00 +0300

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

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

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

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

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

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

nospam@example.com (mssqlhelp) — Mon, 03 Aug 2026 11:27:00 +0300

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

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

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

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

nospam@example.com (Sergey Moiseenko) — Sun, 02 Aug 2026 09:45:00 +0300

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

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

столбцы IDENTITY

объекты SEQUENCE

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

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

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

nospam@example.com (mssqlhelp) — Thu, 30 Jul 2026 14:17:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: enable_indexscan and enable_bitmapscan

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

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

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

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

nospam@example.com (Sergey Moiseenko) — Wed, 29 Jul 2026 09:51:00 +0300

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

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

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

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

nospam@example.com (Sergey Moiseenko) — Mon, 27 Jul 2026 15:20:00 +0300

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

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

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

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

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

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

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

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

и еще

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

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

nospam@example.com (Sergey Moiseenko) — Thu, 23 Jul 2026 18:39:00 +0300

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

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

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

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

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

nospam@example.com (mssqlhelp) — Tue, 21 Jul 2026 09:44:00 +0300

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

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

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

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

nospam@example.com (mssqlhelp) — Sun, 19 Jul 2026 13:51:00 +0300

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

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

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

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

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

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

Почему в Postgres нет synchronous_commit=remote_receive?

nospam@example.com (mssqlhelp) — Sat, 18 Jul 2026 13:22:00 +0300

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

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

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

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

Continue reading "Почему в Postgres нет synchronous_commit=remote_receive?"

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

nospam@example.com (mssqlhelp) — Sun, 19 Jul 2026 13:13:00 +0300

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

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

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

nospam@example.com (mssqlhelp) — Sat, 18 Jul 2026 12:34:00 +0300

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

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

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

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

nospam@example.com (mssqlhelp) — Fri, 17 Jul 2026 17:04:00 +0300

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

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

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

nospam@example.com (mssqlhelp) — Thu, 16 Jul 2026 22:09:00 +0300

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

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

Столбцы JSONB и TOAST в Postgres: пособие по производительности

nospam@example.com (Sergey Moiseenko) — Thu, 16 Jul 2026 09:03:00 +0300

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

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

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

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

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

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

nospam@example.com (mssqlhelp) — Mon, 13 Jul 2026 17:48:00 +0300

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

default_transaction_deferrable устанавливает значение по умолчанию для атрибута транзакции DEFERRABLE для новых транзакций. Значение по умолчанию — off, контекст — user, и атрибут, который он задаёт по умолчанию, не делает ничего, если только не выполнены два других условия, — именно поэтому этот параметр заслуживает нескольких сотен слов, а не одного предложения.

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

Всё о GUC по порядку: default_transaction_isolation and default_transaction_read_only

nospam@example.com (mssqlhelp) — Tue, 14 Jul 2026 18:20:00 +0300

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

Оставшиеся два из трёх параметров default_transaction_*, завершающие набор, начатый параметром default_transaction_deferrable. Каждый из них устанавливает значение по умолчанию для сеанса для одного из трёх свойств транзакции — уровня изоляции, режима доступа и отложенности, — и для всех трёх правило одинаково: область действия GUC редко является той, которая вам нужна. Интересное содержание заключается в том, что означают значения, и для уровня изоляции это больше, чем думает большинство людей.

Continue reading "Всё о GUC по порядку: default_transaction_isolation and default_transaction_read_only"

Аварийное восстановление — это процесс, а не инструмент (Часть 1)

nospam@example.com (mssqlhelp) — Mon, 13 Jul 2026 19:43:00 +0300

Автор: Richard Yen, Disaster Recovery is a Process, Not a Tool (Part 1)

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

Ландшафт изменился

Это уже не тот мир, в котором мы живём сейчас. Время безотказной работы стало гораздо более критичным, чем раньше. Пять девяток когда-то были амбициозной целью — теперь четыре девятки для многих команд являются просто ожидаемым стандартом, и даже несколько минут простоя в месяц кажутся большой проблемой. Мы больше не отслеживаем средние значения в наших метриках; мы отслеживаем p99-задержки, потому что нам действительно важно, чтобы последний 1% пользователей получал хороший опыт работы.

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

Postgres, конечно, не исключение. Именно в таком мире и должен действовать план аварийного восстановления Postgres.

Continue reading "Аварийное восстановление — это процесс, а не инструмент (Часть 1)"

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

nospam@example.com (mssqlhelp) — Sun, 12 Jul 2026 22:05:00 +0300

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

default_toast_compression определяет, какой алгоритм PostgreSQL использует для сжатия значений, направляемых в TOAST — внестрочное хранилище для значений полей, слишком больших, чтобы помещаться непосредственно на странице кучи размером 8 КБ. Доступны варианты pglz и lz4; по умолчанию во всех выпущенных на данный момент версиях используется pglz; контекст — user, и его можно переопределить для каждого столбца с помощью опции COMPRESSION в CREATE TABLE или ALTER TABLE. Параметр существует начиная с PostgreSQL 14, и более интересный факт заключается в том, что его значение по умолчанию, наконец, скоро изменится.

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

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

nospam@example.com (mssqlhelp) — Sat, 11 Jul 2026 11:09:00 +0300

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

default_text_search_config определяет конфигурацию полнотекстового поиска, которую используют функции PostgreSQL для полнотекстового поиска, если вы явно не передаёте им конфигурацию. Значение по умолчанию устанавливается командой initdb на основе локали кластера; контекст — user. Конфигурация полнотекстового поиска связывает парсер (который разбивает текст на токены) с цепочкой словарей (которые преобразуют токены в лексемы — например, приводят «бегущий» к «бежать», отбрасывают стоп-слова вроде «и»), и каждый вызов to_tsvector и to_tsquery нуждается в конфигурации для своей работы. Этот параметр используется теми вызовами, которые опускают явное указание конфигурации.

Это звучит как удобство, и в основном так оно и есть, но этот параметр основан на одном из самых элегантных ограничений PostgreSQL, и именно это ограничение и есть суть данной статьи.

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

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

nospam@example.com (mssqlhelp) — Fri, 10 Jul 2026 23:45:00 +0300

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

Сначала о механике, поскольку она кратка: когда default_tablespace содержит что-либо, кроме пустой строки, он неявно добавляет предложение TABLESPACE к каждой команде CREATE TABLE и CREATE INDEX, в которой это предложение явно не указано, включая индекс, создаваемый для ограничений UNIQUE или PRIMARY KEY. Значение по умолчанию — пустая строка, что означает «использовать табличное пространство самой базы данных», а контекст — user. Чтобы иметь мнение об этом параметре, нужно иметь мнение о табличных пространствах, и моё, в 2026 году, таково: в основном не используйте. Мы ещё дойдём до этого. Сначала — особенности.

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

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

nospam@example.com (mssqlhelp) — Thu, 09 Jul 2026 12:33:00 +0300

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

Небольшая ручка на очень большой двери. default_table_access_method определяет метод доступа к таблицам — то есть механизм хранения, если использовать слово, которое все на самом деле подразумевают, — который получают новые таблицы, если в CREATE TABLE не указано иное. Значение по умолчанию — heap. Контекст — user. И для подавляющего большинства кластеров это значение никогда не было иным, потому что для подавляющего большинства кластеров никогда не существовало ничего другого, на что можно было бы его установить. Параметр интересен тем, что он подразумевает: уровень хранения PostgreSQL в принципе подключаем (pluggable).

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

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

nospam@example.com (mssqlhelp) — Wed, 08 Jul 2026 11:17:00 +0300

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

default_statistics_target — один из наиболее рекомендуемых и наименее объясняемых параметров в PostgreSQL. Руководства по настройке говорят: «Увеличьте до 500 для хранилищ данных» с уверенностью, подобной Большой Советской Энциклопедии, и редко поясняют, что означает это число. Значение по умолчанию — 100, диапазон — от 1 до 10 000, контекст — user, и то, что это число на самом деле контролирует, — размер трёх структур, которые ANALYZE создаёт для каждого столбца. Давайте посмотрим на эти структуры.

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

Всё о GUC по порядку: семейство debug_*

nospam@example.com (mssqlhelp) — Tue, 07 Jul 2026 17:48:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: the debug_* family

Двенадцать параметров имеют общий префикс debug_, и этот префикс несёт смысловую нагрузку: это собственные средства разработки и контроля качества PostgreSQL, доступные в виде параметров времени выполнения, чтобы buildfarm и разработчики ядра могли тестировать различные участки кода без перекомпиляции. Павло Голуб (Pavlo Golub), писавший об одном из них, точно сформулировал правильную позицию: «Я никогда-никогда не прикоснусь к параметру времени выполнения с префиксом "debug" в своих производственных кластерах». В основном это правильно. Давайте разберём эти дюжину параметров по тому, что они на самом деле дают, потому что один-два из них тихо полезны, а остальные вы должны разглядывать с безопасного расстояния.

Continue reading "Всё о GUC по порядку: семейство debug_*"

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

nospam@example.com (mssqlhelp) — Mon, 06 Jul 2026 21:07:00 +0300

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

Название немного вводит в заблуждение. deadlock_timeout — это не время, в течение которого PostgreSQL терпит взаимоблокировку, прежде чем её разорвать, — взаимоблокировки прерываются в тот же миг, как только они обнаружены. Это время, которое процесс ожидает блокировку, прежде чем PostgreSQL вообще удосужится проверить наличие взаимоблокировки. Значение по умолчанию — 1 с, контекст — superuser, и разрыв между тем, что подразумевает название, и тем, что на самом деле делает параметр, и составляет суть данной статьи.

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

Изучаем PostgreSQL вместе с Grant Fritchey: хранилище данных

nospam@example.com (Sergey Moiseenko) — Sun, 05 Jul 2026 20:11:00 +0300

Пересказ статьи Grant Fritchey. Learning PostgreSQL with Grant: Data Storage

Если вы размещаете свои базы данных на виртуальной машине (ВМ) или на каком-то большом железе, одним из наиболее узких мест, с которым вы, вероятно столкнетесь в кластерах PostgreSQL, является ввод/вывод. Когда ввод/вывод находится в центре потенциальных проблем производительности, очень важно понимать, как PostgreSQL управляет им. Я собираюсь начать прямо сейчас с того, как данные хранятся на диске. В следующей статье мы обсудим, как выполняется запись и чтение.

Прежде чем погрузиться в детали, я хочу затронуть пару вопросов, связанных с хранением данных в PostgreSQL. Во-первых, расширения. Некоторые из наиболее впечатляющих расширений напрямую связаны с хранением данных (глядя на TimeScale). Они могут изменить те основы, которые мы собираемся обсуждать здесь. Коли так, каждое из них требует отдельного обсуждения, чтобы понять, как они влияют на хранение в PostgreSQL.
Continue reading "Изучаем PostgreSQL вместе с Grant Fritchey: хранилище данных"

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

nospam@example.com (mssqlhelp) — Sun, 05 Jul 2026 18:10:00 +0300

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

После бездны fsync — нечто благодушное. DateStyle управляет тем, как PostgreSQL выводит даты и как разрешает неоднозначный ввод дат, и единственное, что вам действительно нужно знать о нём: оставьте его в значении ISO, а всё остальное — интересные, но маловажные детали.

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

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

nospam@example.com (mssqlhelp) — Fri, 03 Jul 2026 20:41:00 +0300

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

В чём смысл этого параметра? SHOW data_directory_mode сообщает права доступа Unix на каталог данных — 0700 или 0750 — и это всё, что он делает. Он доступен только для чтения; вы не можете его установить. И он сообщает факт, который ls -ld $PGDATA сообщил бы вам не хуже. Так зачем же он нужен как GUC?

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

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

nospam@example.com (mssqlhelp) — Sat, 04 Jul 2026 19:26:00 +0300

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

data_sync_retry — это логический параметр, по умолчанию выключен (off), и его контекст — postmaster, так что для его изменения требуется перезапуск. Вы почти наверняка никогда его не измените. Он существует как видимый рубец от самого тревожного события, которое сообщество PostgreSQL когда-либо узнало о своих собственных допущениях относительно долговечности, и чтобы объяснить этот единственный параметр, нам придётся объяснить fsyncgate.

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

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

nospam@example.com (mssqlhelp) — Thu, 02 Jul 2026 21:37:00 +0300

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

data_directory указывает расположение каталога данных кластера — того самого каталога, который подразумевают под $PGDATA, содержащего base/, pg_wal/, global/ и всё остальное. Контекст — postmaster: параметр можно задать в postgresql.conf или в командной строке, но никогда во время работы. И, как и небольшое число других параметров, его нельзя установить через ALTER SYSTEM — по очевидной причине: ALTER SYSTEM записывает изменения в postgresql.auto.conf, который находится внутри каталога данных, то есть внутри того самого объекта, который вы пытаетесь указать. Нельзя использовать файл внутри «коробки», чтобы сообщить PostgreSQL, где находится эта коробка.

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

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

Настройка производительности в PostgreSQL 17: создание таблиц, вставка 10М записей и обнаружение неиспользуемых индексов

nospam@example.com (Sergey Moiseenko) — Thu, 02 Jul 2026 19:27:00 +0300

Пересказ статьи Jeyaram Ayyalusamy. PostgreSQL 17 Performance Tuning: Creating Tables, Populating 10M Records, and Detecting Unused Indexes

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

Неиспользуемые или избыточные индексы часто упускаются из виду, хотя они могут незаметно снижать производительность системы. В этой статье мы узнаем, почему это происходит, и на практическом примере создания большого набора данных и построения индексов проанализируем, какие из них действительно полезны.
Continue reading "Настройка производительности в PostgreSQL 17: создание таблиц, вставка 10М записей и обнаружение неиспользуемых индексов"

Файловые дескрипторы: предел ОС, который выводит PostgreSQL из строя

nospam@example.com (mssqlhelp) — Thu, 02 Jul 2026 13:37:00 +0300

Автор: Warda Bibi, File Descriptors: The OS Limit That Takes Down PostgreSQL

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

Continue reading "Файловые дескрипторы: предел ОС, который выводит PostgreSQL из строя"

pg_stat_statements: о чём оно нам говорит

nospam@example.com (mssqlhelp) — Tue, 30 Jun 2026 11:26:00 +0300

Автор: Radim Marek, pg_stat_statements: everything it tells you

Расширение pg_stat_statements — если не первое, то одно из самых используемых в экосистеме PostgreSQL. Оно поставляется в составе contrib и практически не требует затрат на использование. Большинство из нас обращаются к нему, чтобы ответить на вопрос: что на самом деле делает база данных? Это действительно полезно. Вы можете использовать его, чтобы получить снимок того, что происходило в заданный интервал времени, и быстрее принять решение о том, что исправлять.

Continue reading "pg_stat_statements: о чём оно нам говорит"

SQL-Ex blog - Articles

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

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

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

Как узнать последнее значение, используемое последовательностью в SQL Server

Что такое последовательности в SQL Server?

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

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

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

Слишком много таблиц — это плохо

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

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

Обновление кластеров PostgreSQL 19 стало ещё более бесшовным

Всё о GUC по порядку: enable_material и enable_memoize

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

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

pg_stats: как работает внутренняя статистика Postgres

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

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

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

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

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

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

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

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

Комментарии

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

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

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

Почему в Postgres нет synchronous_commit=remote_receive?

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

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

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

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

Столбцы JSONB и TOAST в Postgres: пособие по производительности

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

Всё о GUC по порядку: default_transaction_isolation and default_transaction_read_only

Аварийное восстановление — это процесс, а не инструмент (Часть 1)

Ландшафт изменился

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

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

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

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

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

Всё о GUC по порядку: семейство debug_*

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

Изучаем PostgreSQL вместе с Grant Fritchey: хранилище данных

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

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

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

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

Настройка производительности в PostgreSQL 17: создание таблиц, вставка 10М записей и обнаружение неиспользуемых индексов

Файловые дескрипторы: предел ОС, который выводит PostgreSQL из строя

pg_stat_statements: о чём оно нам говорит