default_toast_compression определяет, какой алгоритм PostgreSQL использует для сжатия значений, направляемых в TOAST — внестрочное хранилище для значений полей, слишком больших, чтобы помещаться непосредственно на странице кучи размером 8 КБ. Доступны варианты pglz и lz4; по умолчанию во всех выпущенных на данный момент версиях используется pglz; контекст — user, и его можно переопределить для каждого столбца с помощью опции COMPRESSION в CREATE TABLE или ALTER TABLE. Параметр существует начиная с PostgreSQL 14, и более интересный факт заключается в том, что его значение по умолчанию, наконец, скоро изменится.
default_text_search_config определяет конфигурацию полнотекстового поиска, которую используют функции PostgreSQL для полнотекстового поиска, если вы явно не передаёте им конфигурацию. Значение по умолчанию устанавливается командой initdb на основе локали кластера; контекст — user. Конфигурация полнотекстового поиска связывает парсер (который разбивает текст на токены) с цепочкой словарей (которые преобразуют токены в лексемы — например, приводят «бегущий» к «бежать», отбрасывают стоп-слова вроде «и»), и каждый вызов to_tsvector и to_tsquery нуждается в конфигурации для своей работы. Этот параметр используется теми вызовами, которые опускают явное указание конфигурации.
Это звучит как удобство, и в основном так оно и есть, но этот параметр основан на одном из самых элегантных ограничений PostgreSQL, и именно это ограничение и есть суть данной статьи.
Сначала о механике, поскольку она кратка: когда default_tablespace содержит что-либо, кроме пустой строки, он неявно добавляет предложение TABLESPACE к каждой команде CREATE TABLE и CREATE INDEX, в которой это предложение явно не указано, включая индекс, создаваемый для ограничений UNIQUE или PRIMARY KEY. Значение по умолчанию — пустая строка, что означает «использовать табличное пространство самой базы данных», а контекст — user. Чтобы иметь мнение об этом параметре, нужно иметь мнение о табличных пространствах, и моё, в 2026 году, таково: в основном не используйте. Мы ещё дойдём до этого. Сначала — особенности.
Небольшая ручка на очень большой двери. default_table_access_method определяет метод доступа к таблицам — то есть механизм хранения, если использовать слово, которое все на самом деле подразумевают, — который получают новые таблицы, если в CREATE TABLE не указано иное. Значение по умолчанию — heap. Контекст — user. И для подавляющего большинства кластеров это значение никогда не было иным, потому что для подавляющего большинства кластеров никогда не существовало ничего другого, на что можно было бы его установить. Параметр интересен тем, что он подразумевает: уровень хранения PostgreSQL в принципе подключаем (pluggable).
default_statistics_target — один из наиболее рекомендуемых и наименее объясняемых параметров в PostgreSQL. Руководства по настройке говорят: «Увеличьте до 500 для хранилищ данных» с уверенностью, подобной Большой Советской Энциклопедии, и редко поясняют, что означает это число. Значение по умолчанию — 100, диапазон — от 1 до 10 000, контекст — user, и то, что это число на самом деле контролирует, — размер трёх структур, которые ANALYZE создаёт для каждого столбца. Давайте посмотрим на эти структуры.
Двенадцать параметров имеют общий префикс debug_, и этот префикс несёт смысловую нагрузку: это собственные средства разработки и контроля качества PostgreSQL, доступные в виде параметров времени выполнения, чтобы buildfarm и разработчики ядра могли тестировать различные участки кода без перекомпиляции. Павло Голуб (Pavlo Golub), писавший об одном из них, точно сформулировал правильную позицию: «Я никогда-никогда не прикоснусь к параметру времени выполнения с префиксом "debug" в своих производственных кластерах». В основном это правильно. Давайте разберём эти дюжину параметров по тому, что они на самом деле дают, потому что один-два из них тихо полезны, а остальные вы должны разглядывать с безопасного расстояния.
Если вы когда-либо оказывались в середине миграции базы данных и внезапно обнаруживали, что ваши слоты логической репликации исчезли, вы знаете, насколько тревожно это ощущение. Никакой очевидной ошибки. Никакого предупреждения. Просто исчезли. Именно это случилось с нами при миграции данных из кластера под управлением Patroni в отдельный кластер PostgreSQL. То, что начиналось как гладкая операция, превратилось в сеанс отладки, который преподал нам важный урок о поведении Patroni после перезапуска.
Название немного вводит в заблуждение. deadlock_timeout — это не время, в течение которого PostgreSQL терпит взаимоблокировку, прежде чем её разорвать, — взаимоблокировки прерываются в тот же миг, как только они обнаружены. Это время, которое процесс ожидает блокировку, прежде чем PostgreSQL вообще удосужится проверить наличие взаимоблокировки. Значение по умолчанию — 1 с, контекст — superuser, и разрыв между тем, что подразумевает название, и тем, что на самом деле делает параметр, и составляет суть данной статьи.
Если вы размещаете свои базы данных на виртуальной машине (ВМ) или на каком-то большом железе, одним из наиболее узких мест, с которым вы, вероятно столкнетесь в кластерах PostgreSQL, является ввод/вывод. Когда ввод/вывод находится в центре потенциальных проблем производительности, очень важно понимать, как PostgreSQL управляет им. Я собираюсь начать прямо сейчас с того, как данные хранятся на диске. В следующей статье мы обсудим, как выполняется запись и чтение.
Прежде чем погрузиться в детали, я хочу затронуть пару вопросов, связанных с хранением данных в PostgreSQL. Во-первых, расширения. Некоторые из наиболее впечатляющих расширений напрямую связаны с хранением данных (глядя на TimeScale). Они могут изменить те основы, которые мы собираемся обсуждать здесь. Коли так, каждое из них требует отдельного обсуждения, чтобы понять, как они влияют на хранение в PostgreSQL. Продолжить чтение "Изучаем PostgreSQL вместе с Grant Fritchey: хранилище данных"
После бездны fsync — нечто благодушное. DateStyle управляет тем, как PostgreSQL выводит даты и как разрешает неоднозначный ввод дат, и единственное, что вам действительно нужно знать о нём: оставьте его в значении ISO, а всё остальное — интересные, но маловажные детали.
data_sync_retry — это логический параметр, по умолчанию выключен (off), и его контекст — postmaster, так что для его изменения требуется перезапуск. Вы почти наверняка никогда его не измените. Он существует как видимый рубец от самого тревожного события, которое сообщество PostgreSQL когда-либо узнало о своих собственных допущениях относительно долговечности, и чтобы объяснить этот единственный параметр, нам придётся объяснить fsyncgate.
В чём смысл этого параметра? SHOW data_directory_mode сообщает права доступа Unix на каталог данных — 0700 или 0750 — и это всё, что он делает. Он доступен только для чтения; вы не можете его установить. И он сообщает факт, который ls -ld $PGDATA сообщил бы вам не хуже. Так зачем же он нужен как GUC?
data_directory указывает расположение каталога данных кластера — того самого каталога, который подразумевают под $PGDATA, содержащего base/, pg_wal/, global/ и всё остальное. Контекст — postmaster: параметр можно задать в postgresql.conf или в командной строке, но никогда во время работы. И, как и небольшое число других параметров, его нельзя установить через ALTER SYSTEM — по очевидной причине: ALTER SYSTEM записывает изменения в postgresql.auto.conf, который находится внутри каталога данных, то есть внутри того самого объекта, который вы пытаетесь указать. Нельзя использовать файл внутри «коробки», чтобы сообщить PostgreSQL, где находится эта коробка.
Эта циркулярная зависимость и составляет всю историю данного параметра, так что давайте разберёмся с ней.
