SQL-Ex blog

Почему в 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_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"

Новости за 2026-07-11 - 2026-07-17

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

§ Автор усилил проверку задачи 241 (SELECT, рейтинг) и поднял ее сложность до 2 баллов.

§ Под номером 242 опубликована новая задачи от gennadi_s (SELECT, рейтинг, сложность 2 балла).

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

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

Continue reading "Новости за 2026-07-11 - 2026-07-17"

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

Новости за 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"