Как стать автором
Обновить

Массовая оптимизация запросов PostgreSQL. Кирилл Боровиков (Тензор)

Время на прочтение 16 мин
Количество просмотров 19K
Всего голосов 30: ↑29 и ↓1 +28
Комментарии 15

Комментарии 15

Спасибо. Планируете ли публиковать в opensource ваш explain, чтобы можно было его локально развернуть?

Посмотрел пример того, как Вы определяете проблемные запросы с помощью полной версии данного инструмента, ну уж очень впечатляет. Лично я буду ждать его в opensource, и возможности использовать в своей инфраструктуре.

И спасибо за explain.tensor.ru

Локализация на английский была бы тоже хорошо.

Замечательный инструмент, и такого инструмента действительно не хватает.

Во всей этой схеме немного расстраивает необходимость скидывать планы в лог (с помощью auto_explain) и далее консолидация всех этих логов.
Вот если бы научить PostgreSQL хранить планы в shared memory как это делает расширение pg_store_plans (сам пока не тестировал), и получать потом эти данные уже обычным sql запросом, как это делается с тем же pg_stat_statements.
Боюсь, в промышленных масштабах на это не хватит никакой памяти, если не закручивать гайки типа pg_stat_statements.max. А если закручивать — то эта статистика становится сильно неактуальной.
Сейчас нет примера для проверки под рукой, но когда делал доклад было так:
1. понимает только JSON, что сильно «жирнее» для лога
2. имеет те же проблемы с CTE Scan, что и depesz

Понятно и интересно изложено. Вам бы продавать этот продукт в большие компании. Синему гиганту бы зашло. Таких спецов там нет, а проблема есть и ещё какая. В каждой дочке серверов хватает, везде есть исторические локальные информационные системы, сопровождаемые локально, часто подрядчиком. Как что-то зависнет, так начинается "расследование" и поиск виновника. То ли сеть в этот момент была перегружена, то ли сервер уже старенький, то ли "ваша программа опять не работает", а списать на случайность нельзя.

А насколько по вашему опыту велики накладные расходы на использование auto_explain? Я в документации по auto_explain.log_analyze вижу
Note: When this parameter is on, per-plan-node timing occurs for all statements executed, whether or not they run long enough to actually get logged. This can have an extremely negative impact on performance.

А как я понимаю без использования этой опции план выполнения будет не особо полезным.
Сильно зависит от сложности и частоты запросов. Обычно +2-3% нагрузки по CPU, ну и диск под логами должен позволять все это писать адекватно быстро.
Во-первых, одним и тем же запросам по разным схемам в рамках одной базы он присваивает разные QueryId. То есть если сначала сделать SET search_path = '01'; SELECT * FROM user LIMIT 1;, а потом SET search_path = '02'; и такой же запрос

Не совсем понял, чем же это плохо, что будут разные queryId?
По-моему это логично, если вы выполняете select * from user в схеме 01, то будет найдена таблица в этой схеме 01.user, а если выполняете в схеме 02, то 02.user. Более, чем вероятно, что это разные по структуре таблицы с разным набором индексов, констрейнтов, триггеров. Или я что-то не так понял?
Обычно, если таблицы в схемах одноименные, то и структура у них одинаковая (потому как если разная — зачем они одинаково названы?).
Мы применяем схемы для разделения однородных пользовательских данных — то есть и структуры, и запросы к ним одинаковы. И нам важно знать, что проблемы с профилем «запроса к user», а не конкретно к 01.user.
Обычно, если таблицы в схемах одноименные, то и структура у них одинаковая

Более чем спорное утверждение. Ваш случай имеет место быть, но он скорее исключение, чем правило.
Почему таблицы могут иметь одинаковое название, но разную структуру? Например, потому что имеют одно название термина, но в разных доменных областях: заявка на подключение, заявка на обслуживание, заявка на отказ и т.д. Да, можно было бы поименовать таблицы с префиксом равным имени домена, но куда логичней создать отдельные схемы с именем домена и сгруппировать объекты бд в рамках этих схем.
Практика показывает, что если вещи называются одинаково, предназначены для одного, участвуют в одних процессах, то и структуру им стоит иметь одинаковую.
Но это если у вас запросы одинаковые и выбор конкретной схемы происходит через SET search_path. А если вы просто обращаетесь в запросе sales.request, payments.request, то для них и планы и шаблоны будут независимыми.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий