SQL-Ex blog

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

Новости за 2026-07-04 - 2026-07-10

nospam@example.com (Sergey Moiseenko) — Fri, 10 Jul 2026 19:48:00 +0300

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

	Участник		w_sel	all_sel	select	dml	Всего	Рейтинг
 Багманов Д.Д.  (Bagmanov_Dinar	20	20	28	11	39	2643
 Шибаев  (saah)                	7	57	18	0	18	1234
 Сафронов П.А.  (Paulus73)     	5	155	14	0	14	134
 Odnokurtsev  (AlFochino)      	3	127	8	59	67	175
 Fom  (Kamchatka)              	3	9	5	0	5	5634
 Smirnov S. (hr)               	3	28	4	0	4	1388

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

Рейтинг	 Участник (решенные задачи, время в днях)
 134		Paulus73 (155, 15.028)
 140		Rujan (143, 451.925)
 169		Tigra1 (138, 24.441)
 175		AlFochino (127, 121.400)

Continue reading "Новости за 2026-07-04 - 2026-07-10"

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

Когда Patroni молча удаляет ваши слоты репликации

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

Автор: Semab Tariq, When Patroni Silently Deletes Your Replication Slots

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

Continue reading "Когда Patroni молча удаляет ваши слоты репликации"

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

Новости за 2026-06-27 - 2026-07-03

nospam@example.com (Sergey Moiseenko) — Fri, 03 Jul 2026 18:33:00 +0300

§ Изменения среди лидеров рейтинга

Рейтинг	Участник (решенные задачи)
 20		Dmitriy Varenikov (251)

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

	Участник		w_sel	all_sel	select	dml	Всего	Рейтинг
 Никольский И.Ю.  (igoryun)    	9	63	18	11	29	641
 Сафронов П.А.  (Paulus73)     	7	150	14	0	14	135
 Шибаев  (saah)                	9	50	14	0	14	1452
 Gitinomagomedov  (gmansur88)  	5	64	11	1	12	725
 fioletovaya  (fioletovaya2)   	2	138	9	0	9	144
 Palela D. (Davitapalela)      	4	4	6	20	26	4132
 Скоков Б.С.  (leks$$)         	2	37	6	0	6	1325
 Вареников Д.М.  (Dmitriy Varen	2	230	5	0	5	20
 P I.*.  (IrinaPetr)           	2	86	5	0	5	520
 Odnokurtsev  (AlFochino)      	2	124	4	0	4	253
 Vladimirovich V.B.  (vladimirb	2	5	4	0	4	6573

Continue reading "Новости за 2026-06-27 - 2026-07-03"

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

nospam@example.com (mssqlhelp) — Wed, 01 Jul 2026 15:36:00 +0300

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

Параметр только для чтения, подобно block_size, — команда SHOW data_checksums сообщает, включены ли в кластере контрольные суммы страниц, и это единственное взаимодействие, которое предлагает данный GUC. Но, в отличие от block_size, у этого параметра тринадцатилетняя история, которая всё ещё пишется, и эта история и есть предмет данной статьи.

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

Всё о 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: о чём оно нам говорит"

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

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

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

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

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

pg_stat_statements: всё, что оно не может

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

Автор: Radim Marek, pg_stat_statements: everything it can't

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

Continue reading "pg_stat_statements: всё, что оно не может"

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

nospam@example.com (mssqlhelp) — Mon, 29 Jun 2026 16:35:00 +0300

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

createrole_self_grant — небольшой, недавний (PostgreSQL 16) и почти невозможный для объяснения изолированно. Чтобы рассказать, что он делает, нам нужно поговорить о том, какой была система ролей до 16-й версии, какой она стала сейчас и почему произошли изменения. Этот параметр является одним из видимых артефактов довольно существенного пересмотра, и этот пересмотр интереснее самого параметра.

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

Ночь, когда наши таблицы не переставали расти

nospam@example.com (mssqlhelp) — Mon, 29 Jun 2026 15:46:00 +0300

Автор: Semab Tariq, The Night Our Tables Wouldn’t Stop Growing

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

Что-то было серьёзно не так, и мы понятия не имели, что именно.

Continue reading "Ночь, когда наши таблицы не переставали расти"

Всё о GUC по порядку: cpu_index_tuple_cost, cpu_operator_cost и cpu_tuple_cost

nospam@example.com (mssqlhelp) — Sun, 28 Jun 2026 18:41:00 +0300

Автор: Christophe Pettus, All Your GUCs in a Row: cpu_index_tuple_cost, cpu_operator_cost и cpu_tuple_cost

cpu_tuple_cost, cpu_index_tuple_cost и cpu_operator_cost — это три константы, которые планировщик использует для оценки стоимости запроса. Самое полезное, что можно знать о всех трёх — это то, что вам почти наверняка никогда не следует их менять. Остальная часть статьи объясняет, почему.

Continue reading "Всё о GUC по порядку: cpu_index_tuple_cost, cpu_operator_cost и cpu_tuple_cost"

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

nospam@example.com (mssqlhelp) — Sun, 28 Jun 2026 00:12:00 +0300

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

constraint_exclusion управляет трюком планировщика: когда таблица имеет ограничение CHECK, планировщик может сравнить это ограничение с условием WHERE вашего запроса и, если они противоречат друг другу, пропустить сканирование таблицы целиком.

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

Сравнение DATE_BUCKET и DATETRUNC

nospam@example.com (Sergey Moiseenko) — Sat, 27 Jun 2026 09:02:00 +0300

Пересказ статьи Chad Callihan. Comparing DATE_BUCKET and DATETRUNC

Если вы не много экспериментировали с SQL Server 2022, вы может быть незнакомы с функциями DATE_BUCKET и DATETRUNC. Обе они полезны, когда дело доходит до агрегирования данных. Давайте рассмотрим каждую из этих функций на нескольких примерах.

DATE_BUCKET

Начнем с DATE_BUCKET. DATE_BUCKET дает вам возможность агрегировать данные на основе выбранного вами интервала. Допустим, мы имеем такой набор событий:

Continue reading "Сравнение DATE_BUCKET и DATETRUNC"

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

nospam@example.com (mssqlhelp) — Fri, 26 Jun 2026 21:34:00 +0300

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

config_file сообщает серверу PostgreSQL, где находится postgresql.conf, что должно заставить вас на мгновение задуматься. Если сервер узнаёт, где находится его файл конфигурации, из параметра, а параметры берутся из файла конфигурации, как он вообще находит первый файл?

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

Новости за 2026-06-20 - 2026-06-26

nospam@example.com (Sergey Moiseenko) — Fri, 26 Jun 2026 18:37:00 +0300

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

Топик		Сообщений	Просмотров
 53 (DML)		3		5
 18 (Learn)		2		11
 7 (Learn)		2		14

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

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

§ Изменения среди лидеров рейтинга

Рейтинг	Участник (решенные задачи)
 35		BW (262)

Continue reading "Новости за 2026-06-20 - 2026-06-26"

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

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

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

compute_query_id по умолчанию имеет значение auto, потому что разработчики PostgreSQL оказались в тупике. PostgreSQL 14 переместил вычисление идентификатора запроса в ядро сервера, чтобы всё, что нуждается в идентификаторе запроса — pg_stat_statements, pg_stat_activity, EXPLAIN и журналы, — могло использовать одно каноническое значение вместо того, чтобы в каждом случае изобретать своё. Это оставило вопрос о том, каким должно быть значение по умолчанию, и оба очевидных ответа были плохими. Вычислять идентификатор для всех — значит облагать каждый фоновый процесс хэшированием, которое ему, возможно, никогда не понадобится; не вычислять ни для кого — значит незаметно сломать все стеки мониторинга и руководства по настройке, которые предполагали наличие идентификаторов запросов. auto — это выход: вычислять идентификатор только тогда, когда кто-то, кому он нужен, запрашивает его.

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

Как хакнуть издателя в логической репликацмм

nospam@example.com (mssqlhelp) — Thu, 25 Jun 2026 14:27:00 +0300

Авторы: Zhijie Hou, Hayato Kuroda, How to hack the Publisher

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

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

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

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

Continue reading "Как хакнуть издателя в логической репликацмм"

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

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

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

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

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

Всё о GUC по порядку: commit_delay и commit_siblings

nospam@example.com (mssqlhelp) — Tue, 23 Jun 2026 21:29:00 +0300

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

commit_delay — это та единственная настройка, которая говорит групповой фиксации (group commit) PostgreSQL ждать более многочисленной группы. База данных уже сама группирует сбросы WAL: когда один фоновый процесс выполняет сброс WAL, другие, готовые к фиксации, выстраиваются за ним и присоединяются к тому же fsync. commit_delay заставляет процесс, инициирующий этот сброс, сделать паузу на заданное количество микросекунд перед его началом, в предположении, что за время паузы подойдут ещё несколько транзакций и присоединятся к группе. commit_siblings — это сторожевой параметр, который решает, стоит ли вообще делать эту паузу.

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

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

nospam@example.com (mssqlhelp) — Mon, 22 Jun 2026 23:05:00 +0300

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

cluster_name выглядит как косметический параметр: метка, которая отображается в выводе ps, чтобы вы могли различать свои три экземпляра Postgres. На первичном сервере это всё, что он делает. На резервном сервере (standby) он может незаметно стать именем, которое первичный сервер использует, чтобы определить, удовлетворена ли синхронная репликация, — это гораздо более серьёзная задача для параметра, который большинство людей устанавливают и забывают.

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

Восстановление журнала транзакций базы данных SQL Server

nospam@example.com (Sergey Moiseenko) — Mon, 22 Jun 2026 18:42:00 +0300

Пересказ статьи davidfowler. Rebuilding a SQL Server Database Transaction Log

"Не могли бы вы помочь мне, мы удалили файл журнала транзакций базы данных и теперь она застряла в ‘Recovery Pending’?"

Такой крик о помощи я получил пару недель назад.

"Конечно, без проблем, нам придется восстановить вашу последнюю резервную копию", - ответил я.

А потом неизбежное: "Это только база данных разработки, мы не делаем резервных копий."

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

Итак мы имеем следующую ситуацию: база данных недоступна, отсутствует журнал транзакции и нет резервной копии. Что можно сделать? Фактически у нас есть только один вариант - мы должны восстановить журнал транзакций.
Continue reading "Восстановление журнала транзакций базы данных SQL Server"

pretty_explain_*: как сделать планы запросов PostgreSQL читаемыми и стабильными для тестов

nospam@example.com (mssqlhelp) — Sun, 21 Jun 2026 13:42:00 +0300

Автор: Andrei Lepikhov, EXPLAIN Prettier, or Post-Processing Query Plans in Postgres

Эта история началась с книги, подаренной коллегой. Читая книгу Джимми Ангелакоса «PostgreSQL Mistakes and How to Avoid Them», я осознал одну вещь, которая давно меня беспокоила: в Postgres команда EXPLAIN выдаёт слишком много информации. Примеры, которые авторы обычно приводят при обсуждении различных аспектов систем баз данных, усложняют анализ рассматриваемой проблемы и отвлекают читателя. Так родилась идея пост-обработки вывода EXPLAIN — чтобы сделать планы запросов более читаемыми и сфокусированными на проблеме.

Continue reading "pretty_explain_*: как сделать планы запросов PostgreSQL читаемыми и стабильными для тестов"

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

nospam@example.com (mssqlhelp) — Sun, 21 Jun 2026 13:33:00 +0300

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

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

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

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

nospam@example.com (mssqlhelp) — Sat, 20 Jun 2026 12:41:00 +0300

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

client_encoding объявляет, в какой кодировке символов говорит клиент. Сервер использует этот параметр для преобразования между своей внутренней кодировкой (устанавливается во время initdb, для каждой базы данных, часто UTF-8) и тем, что клиент отправляет и ожидает получить. Значение по умолчанию — «the server’s encoding», то есть без преобразования. Контекст параметра — user, с переменной окружения PGCLIENTENCODING, которую libpq учитывает автоматически, по аналогии с application_name.

В мире UTF-8 этот параметр редко проявляется. Сервер — UTF-8, клиент — UTF-8, преобразования не происходит, жизнь хороша. Но «редко проявляется» — это не то же самое, что «не существует», и случаи, когда он проявляется, стоят понимания.

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

Новости за 2026-06-13 - 2026-06-19

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

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

	Участник		w_sel	all_sel	select	dml	Всего	Рейтинг
 Шибаев  (saah)                	13	37	18	0	18	1789
 Сафронов П.А.  (Paulus73)     	5	139	17	0	17	139
 Быков  (EvgenyAstro)          	10	10	15	11	26	4131
 Виноградова С.М.  (Tigra1)    	3	135	8	0	8	182
 Макаров И.А.  (_Bkmz_)        	1	180	5	0	5	49
 P I.*.  (IrinaPetr)           	3	81	5	0	5	608
 Gitinomagomedov  (gmansur88)  	4	52	5	0	5	1052
 Odnokurtsev  (AlFochino)      	1	122	4	0	4	256

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

Рейтинг	 Участник (решенные задачи, время в днях)
 139		Paulus73 (139, 11.160)
 141		Rujan (143, 451.925)
 182		Tigra1 (135, 22.569)

Continue reading "Новости за 2026-06-13 - 2026-06-19"

Всё о GUC по порядку: checkpoint_flush_after и checkpoint_warning

nospam@example.com (mssqlhelp) — Fri, 19 Jun 2026 12:15:00 +0300

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

Два параметра, смежных с контрольными точками, объединённые алфавитной близостью, а не тематическим родством. checkpoint_flush_after — третий из четырёх параметров *_flush_after для выталкивания (writeback); checkpoint_warning — это журнальный параметр, который выводит предупреждение, когда контрольные точки срабатывают слишком часто. Разные задачи, разная аудитория, но ни один из них не требует 400 слов отдельно.

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

Всё о GUC по порядку: checkpoint_timeout и checkpoint_completion_target

nospam@example.com (mssqlhelp) — Thu, 18 Jun 2026 12:25:00 +0300

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

Кластер параметров на букву C открывается первыми двумя параметрами контрольных точек. Мы выводим их из алфавитного порядка, потому что checkpoint_completion_target определён как доля от checkpoint_timeout и не имеет смысла без него. Алфавит может подождать одну статью.

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

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

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

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

Параметр, о котором большинство операторов никогда не знали, хотя каждый дамп-файл PostgreSQL, который они когда-либо просматривали, устанавливает его. check_function_bodies управляет тем, проверяет ли PostgreSQL тело функции при создании CREATE FUNCTION или CREATE PROCEDURE. Значение по умолчанию — on. Контекст параметра — user.

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

Иерархические типы данных

nospam@example.com (Sergey Moiseenko) — Tue, 16 Jun 2026 23:34:00 +0300

Пересказ статьи Florent Jardin. Hierarchical data types

Стандарт SQL определяет ряд правил, которые позволяют системам баз данных быть взаимозаменяемыми, но в реальности есть небольшие особенности. В этой связи тип данных hierarchyid в SQL Server является показательным примером. Если вы перейдете на PostgreSQL, вам будут доступны два решения.

Первое и более простое решение - это связать каждый узел со своим родителем, используя новый столбец parentid и применяя ограничение внешнего ключа. Другой более сложный подход заключается в использовании расширения ltree. В данной статье рассматривается последний вариант.
Continue reading "Иерархические типы данных"

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

nospam@example.com (mssqlhelp) — Tue, 16 Jun 2026 13:16:00 +0300

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

bytea_output управляет тем, как PostgreSQL форматирует двоичные данные при отправке клиенту. Два значения: hex (значение по умолчанию, начиная с PostgreSQL 9.0, вышедшего в 2010 году) и escape (традиционный формат, уходящий корнями в начало 2000-х). Контекст параметра — user. Параметр влияет только на вывод — ввод bytea принимал оба формата всегда, и установка SET bytea_output ничего не меняет в том, как вы записываете литеральные значения.

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

Всё о GUC по порядку: bonjour и bonjour_name

nospam@example.com (mssqlhelp) — Mon, 15 Jun 2026 12:18:00 +0300

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

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

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

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

nospam@example.com (mssqlhelp) — Sun, 14 Jun 2026 12:14:00 +0300

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

Параметр, который вы не можете изменить. block_size находится в разделе «Предустановленные параметры» (Preset Options) документации, вместе со своими «кузенами» только для чтения, такими как data_checksums, wal_block_size и server_version. Он сообщает размер страницы PostgreSQL — фундаментальной единицы хранения на диске и учёта в буферном пуле. Значение по умолчанию — 8192 байта. Он доступен только для чтения во время выполнения, может быть установлен только во время компиляции PostgreSQL, а его изменение после создания кластера означает, что нужно начать всё заново с новым кластером.

Так зачем же он вообще в pg_settings? Потому что всё в базе данных измеряется в единицах этого размера.

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

Методы разбиения на страницы в SQL: повышение производительности запросов и эффективное управление памятью

nospam@example.com (Sergey Moiseenko) — Sat, 13 Jun 2026 23:42:00 +0300

Пересказ статьи Pradip Bhusnar. SQL Pagination Techniques: Enhancing Query Performance and Managing Memory Efficiently

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

Основные методы эффективной разбивки на страницы в SQL

1. Limit и Offset:

Традиционная разбивка на страницы с использованием LIMIT и OFFSET проста, но может оказаться неэффективной при больших смещениях.

Например:

SELECT * FROM data_table

ORDER BY timestamp DESC

LIMIT 10 OFFSET 1000;

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

Continue reading "Методы разбиения на страницы в SQL: повышение производительности запросов и эффективное управление памятью"

Новости за 2026-06-06 - 2026-06-12

nospam@example.com (Sergey Moiseenko) — Sat, 13 Jun 2026 09:16:00 +0300

§ Задача 303 перенесена на третий этап под номером 241.

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

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

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

Всё о GUC по порядку: debug_* family

nospam@example.com (mssqlhelp) — Thu, 11 Jun 2026 10:31:00 +0300

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

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

Continue reading "Всё о GUC по порядку: debug_* family"

Зло (и польза) DISTINCT

nospam@example.com (Sergey Moiseenko) — Tue, 09 Jun 2026 16:16:00 +0300

Пересказ статьи Louis Davidson. The evil (and value) of DISTINCT

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

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

В этой статье я рассмотрю правильное и явно опасное использование DISTINCT, а также покажу, как вы можете протестировать ваш запрос, который использует DISTINCT, чтобы увидеть, что он на самом деле скрывает.
Continue reading "Зло (и польза) DISTINCT"

Всё о GUC по порядку: bgwriter_delay и bgwriter_flush_afte

nospam@example.com (mssqlhelp) — Sun, 07 Jun 2026 13:23:00 +0300

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

Кластер параметров на букву B меняет направление: от разовых странностей к параметрам фонового процесса записи (background writer), которых насчитывается четыре GUC. Первые два мы рассмотрим как пару, потому что bgwriter_delay знакомит нас с самим процессом, а bgwriter_flush_after органично вписывается в экскурсию по механизму writeback из статьи про backend_flush_after.

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