Небольшая ручка на очень большой двери. 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, где находится эта коробка.
Эта циркулярная зависимость и составляет всю историю данного параметра, так что давайте разберёмся с ней.
При настройке PostgreSQL большинство разработчиков и администраторов баз данных сосредотачиваются на поиске отсутствующих индексов, чтобы ускорить запросы. Это важный этап, но есть другая сторона медали: иногда вам требуется обнаружить индексы, которых вообще не следует иметь.
Большинство отказов PostgreSQL, связанных с исчерпанием файловых дескрипторов, ошибочно воспринимаются как проблема самой базы данных. Отказ происходит на уровень ниже: ядро исчерпывает файловые дескрипторы, и удар принимает на себя PostgreSQL. В этой статье рассказывается, как это происходит в условиях большого количества подключений, как читать последовательность записей в журнале при возникновении проблемы и как её исправить.
В первой части был изложен основной тезис: pg_stat_statements считает, а не записывает. В ней было показано, как перемешивание queryid разбивает один логический запрос на множество строк, как зафиксированный при первом появлении текст «замораживает» ваши теги на каждый запрос и как усреднённые значения скрывают тот p99, который на самом деле заставляет вас просыпаться по ночам. Всё это касалось данных, которые расширение собирает, но искажает.
Параметр только для чтения, подобно block_size, — команда SHOW data_checksums сообщает, включены ли в кластере контрольные суммы страниц, и это единственное взаимодействие, которое предлагает данный GUC. Но, в отличие от block_size, у этого параметра тринадцатилетняя история, которая всё ещё пишется, и эта история и есть предмет данной статьи.
