client_min_messages управляет тем, сколько сервер говорит вам: сообщения, которые возвращаются по сети в ваш сеанс. Его постоянно путают с параметром, управляющим тем, что сервер записывает в свой собственный журнал. Это разные задачи с разными параметрами, и путаница — это то место, где начинается большинство проблем.
client_encoding объявляет, в какой кодировке символов говорит клиент. Сервер использует этот параметр для преобразования между своей внутренней кодировкой (устанавливается во время initdb, для каждой базы данных, часто UTF-8) и тем, что клиент отправляет и ожидает получить. Значение по умолчанию — «the server’s encoding», то есть без преобразования. Контекст параметра — user, с переменной окружения PGCLIENTENCODING, которую libpq учитывает автоматически, по аналогии с application_name.
В мире UTF-8 этот параметр редко проявляется. Сервер — UTF-8, клиент — UTF-8, преобразования не происходит, жизнь хороша. Но «редко проявляется» — это не то же самое, что «не существует», и случаи, когда он проявляется, стоят понимания.
Два параметра, смежных с контрольными точками, объединённые алфавитной близостью, а не тематическим родством. checkpoint_flush_after — третий из четырёх параметров *_flush_after для выталкивания (writeback); checkpoint_warning — это журнальный параметр, который выводит предупреждение, когда контрольные точки срабатывают слишком часто. Разные задачи, разная аудитория, но ни один из них не требует 400 слов отдельно.
Кластер параметров на букву C открывается первыми двумя параметрами контрольных точек. Мы выводим их из алфавитного порядка, потому что checkpoint_completion_target определён как доля от checkpoint_timeout и не имеет смысла без него. Алфавит может подождать одну статью.
Параметр, о котором большинство операторов никогда не знали, хотя каждый дамп-файл PostgreSQL, который они когда-либо просматривали, устанавливает его. check_function_bodies управляет тем, проверяет ли PostgreSQL тело функции при создании CREATE FUNCTION или CREATE PROCEDURE. Значение по умолчанию — on. Контекст параметра — user.
Стандарт SQL определяет ряд правил, которые позволяют системам баз данных быть взаимозаменяемыми, но в реальности есть небольшие особенности. В этой связи тип данных hierarchyid в SQL Server является показательным примером. Если вы перейдете на PostgreSQL, вам будут доступны два решения.
Первое и более простое решение - это связать каждый узел со своим родителем, используя новый столбец parentid и применяя ограничение внешнего ключа. Другой более сложный подход заключается в использовании расширения ltree. В данной статье рассматривается последний вариант. Continue reading "Иерархические типы данных"
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;
Проблемы производительности: по мере увеличения смещения базе данных приходится сканировать больше строк, что может привести к значительному падению производительности.