Кластер параметров на букву C открывается первыми двумя параметрами контрольных точек. Мы выводим их из алфавитного порядка, потому что checkpoint_completion_target определён как доля от checkpoint_timeout и не имеет смысла без него. Алфавит может подождать одну статью.
Параметр, о котором большинство операторов никогда не знали, хотя каждый дамп-файл PostgreSQL, который они когда-либо просматривали, устанавливает его. check_function_bodies управляет тем, проверяет ли PostgreSQL тело функции при создании CREATE FUNCTION или CREATE PROCEDURE. Значение по умолчанию — on. Контекст параметра — user.
Стандарт SQL определяет ряд правил, которые позволяют системам баз данных быть взаимозаменяемыми, но в реальности есть небольшие особенности. В этой связи тип данных hierarchyid в SQL Server является показательным примером. Если вы перейдете на PostgreSQL, вам будут доступны два решения.
Первое и более простое решение - это связать каждый узел со своим родителем, используя новый столбец parentid и применяя ограничение внешнего ключа. Другой более сложный подход заключается в использовании расширения ltree. В данной статье рассматривается последний вариант. Продолжить чтение "Иерархические типы данных"
bytea_output управляет тем, как PostgreSQL форматирует двоичные данные при отправке клиенту. Два значения: hex (значение по умолчанию, начиная с PostgreSQL 9.0, вышедшего в 2010 году) и escape (традиционный формат, уходящий корнями в начало 2000-х). Контекст параметра — user. Параметр влияет только на вывод — ввод bytea принимал оба формата всегда, и установка SET bytea_output ничего не меняет в том, как вы записываете литеральные значения.
Параметр, который вы не можете изменить. block_size находится в разделе «Предустановленные параметры» (Preset Options) документации, вместе со своими «кузенами» только для чтения, такими как data_checksums, wal_block_size и server_version. Он сообщает размер страницы PostgreSQL — фундаментальной единицы хранения на диске и учёта в буферном пуле. Значение по умолчанию — 8192 байта. Он доступен только для чтения во время выполнения, может быть установлен только во время компиляции PostgreSQL, а его изменение после создания кластера означает, что нужно начать всё заново с новым кластером.
Так зачем же он вообще в pg_settings? Потому что всё в базе данных измеряется в единицах этого размера.
Эффективная обработка разбивки на страницы (пагинация) в SQL, особенно в высоконагруженных системах, требует тщательного учета как использования памяти, так и производительности. Здесь представлен детальный обзор проектирования и эффективного применения запросов постраничной разбивки.
Основные методы эффективной разбивки на страницы в SQL
1. Limit и Offset:
Традиционная разбивка на страницы с использованием LIMIT и OFFSET проста, но может оказаться неэффективной при больших смещениях.
Например:
SELECT * FROM data_table
ORDER BY timestamp DESC
LIMIT 10 OFFSET 1000;
Проблемы производительности: по мере увеличения смещения базе данных приходится сканировать больше строк, что может привести к значительному падению производительности.
Двенадцать параметров имеют префикс debug_, и этот префикс является значимым: это собственные средства разработки и контроля качества PostgreSQL, предоставленные в виде настроек времени выполнения, чтобы сборочная ферма (buildfarm) и разработчики ядра могли тестировать пути кода без перекомпиляции. Pavlo Golub, пишущий об одном из них, подвёл итог правильному подходу: «Я никогда-никогда не буду трогать параметр времени выполнения с префиксом “debug” в своих производственных кластерах». В основном это правильно. Давайте разберём дюжину параметров и то, что они на самом деле дают, потому что один или два тихо полезны, а остальными стоит восхищаться с безопасного расстояния.
Есть ли в SQL ключевое слово, которое вызывало бы больший страх, чем DISTINCT. Когда я вижу его в запросе, то сразу начинаю беспокоиться о том, сколько работы мне предстоит сделать, чтобы убедиться в правильности этого запроса. Я начинаю искать комментарии, объясняющие, почему оно тут находится, и если не обнаруживаю, то знаю, что запрос, вероятно, будет неправильным.
Я наблюдал такие DISTINCT, которые скрывали плохие соединения, отсутствующую группировку и даже пропущенные предложения WHERE. Я видел разработчиков, которые использовали его как "универсальное решение" проблем с данными.
В этой статье я рассмотрю правильное и явно опасное использование DISTINCT, а также покажу, как вы можете протестировать ваш запрос, который использует DISTINCT, чтобы увидеть, что он на самом деле скрывает. Продолжить чтение "Зло (и польза) DISTINCT"
Кластер параметров на букву B меняет направление: от разовых странностей к параметрам фонового процесса записи (background writer), которых насчитывается четыре GUC. Первые два мы рассмотрим как пару, потому что bgwriter_delay знакомит нас с самим процессом, а bgwriter_flush_after органично вписывается в экскурсию по механизму writeback из статьи про backend_flush_after.
Полнотекстовые индексы - это особый тип индекса, который позволяет быстро и эффективно выполнять поиск по данным, используя довольно экзотические режимы поиска. В MySQL эти режимы включают, но не ограничиваются ими, логический режим, режим естественного языка и режим поиска с использованием расширения запроса. Некоторые из режимов поиска, ставшие возможными благодаря использованию полнотекстовых индексов, предоставляют уникальную поддержку для различной интерпретации определенных символов, поиска подразумеваемых данных и других специфических нюансов.
Параметр для разработчиков (developer option) и действительно полезный. backtrace_functions принимает разделённый запятыми список имён внутренних C-функций; если ошибка возникает внутри любой функции из списка, PostgreSQL записывает трассировку стека на уровне C (C-level stack trace) в журнал сервера вместе с ошибкой. Добавлен в PostgreSQL 13. Значение по умолчанию — пустая строка. Контекст — superuser (или любой пользователь с соответствующим привилегией SET). Доступен не на всех платформах, и качество вывода зависит от того, как был скомпилирован PostgreSQL.
Это необычная область для оператора — это параметр для исследования исходного кода самого сервера, когда что-то идёт не так, а не для настройки поведения. Но если вы когда-либо смотрели на ошибку ERROR: tuple concurrently updated или cache lookup failed for relation NNNNN и задавались вопросом «откуда это в исходном коде», это инструмент для вас.
Первый исторический артефакт в кластере параметров на букву B. backslash_quote управляет тем, принимается ли \' как способ представления одиночной кавычки внутри строкового литерала SQL. Он существует из-за уязвимости SQL-инъекции 2006 года, связанной с многобайтовыми кодировками символов, и почти двадцать лет спустя он всё ещё находится в списке GUC, потому что его удаление нарушило бы работу какого-нибудь приложения где-то. PostgreSQL консервативен в таких вопросах.