В EXPLAIN вы видите два последовательных шага: Seq Scan с cost=0.00..120000.00 и затем Aggregate с cost=120000.00..120500.00. С чего логичнее начать поиск узкого места?
AС шага с самой большой «стоимостью» и объёмом данных (здесь
Seq Scan), потому что он кормит все остальные узлы плана.BС верхней строки плана, потому что она выполняется первой и задаёт порядок чтения данных всеми нижними узлами.
CС любого шага, где встречается слово
Aggregate, потому что агрегаты всегда самые дорогие в плане выполнения.DС названия индекса в плане: если индекса нет в списке узлов, значит запрос обречён на медленное выполнение.
Правильный ответ. Ищите тяжёлые узлы по
cost и rows и помните, что «нижние» шаги кормят «верхние».Разбор
Обычно имеет смысл смотреть на узлы, которые читают или генерируют много строк (часто это сканы и сортировки). Если «внизу» много работы, то «наверху» это уже не исправить. Поле cost — не время выполнения, но оно помогает быстро понять, где планировщик ожидает основные затраты, а rows показывает объём данных между узлами.
Можно заниматься бесплатно
Готовим вопросы…
Три вопроса по теме этой страницы, с объяснениями.
Ещё вопросы по теме «EXPLAIN и оптимизация»
- Вы хотите добавить новый запрос в дашборд и боитесь, что он сильно нагрузит базу, потому что таблица `events` очень большая. Что даёт запуск `EXPLAIN` для этого запроса?
- В выводе `EXPLAIN` вы видите узел `Seq Scan on orders`. Что это обычно означает в плане выполнения запроса?
- В плане `EXPLAIN` для запроса по пользователю вы видите проход по индексу `orders_user_id_idx` для таблицы заказов. Какой вывод наиболее корректен?
- На большой таблице `events` запрос `SELECT * FROM events ORDER BY created_at DESC LIMIT 100` неожиданно работает быстро. Какое объяснение наиболее вероятно при наличии индекса по `created_at`?
- Есть индекс по `orders.created_at`, но `EXPLAIN` для фильтра `WHERE date(created_at) = current_date` показывает `Seq Scan`. Почему это часто происходит?
- Все вопросы по «EXPLAIN и оптимизация» →