Эта история началась с книги, подаренной коллегой. Читая книгу Джимми Ангелакоса «PostgreSQL Mistakes and How to Avoid Them», я осознал одну вещь, которая давно меня беспокоила: в Postgres команда EXPLAIN выдаёт слишком много информации. Примеры, которые авторы обычно приводят при обсуждении различных аспектов систем баз данных, усложняют анализ рассматриваемой проблемы и отвлекают читателя. Так родилась идея пост-обработки вывода EXPLAIN — чтобы сделать планы запросов более читаемыми и сфокусированными на проблеме.
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. В данной статье рассматривается последний вариант. Продолжить чтение "Иерархические типы данных"
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"
