Параметр, который вы не можете изменить. 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 консервативен в таких вопросах.
Каждый кортеж кучи (heap tuple) живёт внутри страницы размером строго 8 КБ. Всё остальное построено поверх этого жёсткого ограничения: MVCC, HOT update и индексы, указывающие на (страница, указатель_строки). И тем не менее, это всё ещё работает:
CREATE TABLE docs (id int PRIMARY KEY, body jsonb);
INSERT INTO docs VALUES (1, (SELECT jsonb_agg(g) FROM generate_series(1, 100000) g));
Это значение body где-то за полмегабайта. Страница кучи по-прежнему имеет размер 8 КБ. Оба утверждения истинны одновременно, и механизм, который позволяет им сосуществовать, называется TOAST: The Oversized-Attribute Storage Technique (техника хранения чрезмерно больших атрибутов).
Прозрачное шифрование данных (Transparent Data Encryption, TDE) стало обязательным требованием для многих предприятий, хранящих конфиденциальные данные, будь то персональные или финансовые. Однако этот эффект обычно означает, что резервные копии бесполезны без отдельного хранимого ключа шифрования, а запуск самого сервера может не выполняться в полностью автоматизированном режиме (в зависимости от того, как настроено управление ключами). Взаимодействие между этими компонентами не всегда интуитивно понятно. Данная статья призвана внести ясность.
Этот документ по планированию содержит базовое введение или обзор как высокой доступности, так и прозрачного шифрования данных, а затем даёт обзор операционных проблем, связанных с совместным использованием этих двух технологий. Рекомендации касаются как инфраструктуры, которую следует учитывать, так и процессов, которые необходимо документировать, тестировать и отрабатывать.
Мы открываем кластер параметров на букву B параметром, само существование которого является признанием сложных отношений. У PostgreSQL сложные отношения с кэшем страниц Linux (page cache), и backend_flush_after — один из четырёх GUC, которые существуют для управления этими отношениями. Остальные три — bgwriter_flush_after, checkpoint_flush_after и wal_writer_flush_after — получат свои собственные статьи в своё время. Они используют общий механизм и имеют общую мотивацию, и эту мотивацию стоит понять, прежде чем мы погрузимся в конкретный параметр.
Последняя запись в кластере параметров автовакуума и самая новая. PostgreSQL 18 представил autovacuum_worker_slots для решения давней операционной проблемы: изменение autovacuum_max_workers ранее требовало перезапуска сервера, что делало невозможным реагирование на меняющуюся рабочую нагрузку вакуума без окна обслуживания. PG 18 исправляет это, разделяя параметр на две части.
