больше маленьких операций, тем больше измерений и больше оверхед?)
the current implementation of EXPLAIN ANALYZE adds profiling overhead to query execution
- то есть в идеале это все-таки проценты или десятки процентов
Обычно время выполнения запроса, показываемое explain analyze почти не отличается от времени выполнения запроса без него. gettimeofday в большинстве систем реализован достаточно эффективно и не требует system call-а. Так что разница не должна превышать единиц процентов. Мне казалось, что негативный эффект на скорость работы от включённого auto_explain скорее будет связан с значительным увеличением объёма записи в лог файл. Но это почти не зависит от того включён ли analyze или нет.
мне всегда хватало нескольких скриптов один из которіх анализирует разницу между seq_scan и idx_scan чем показывает где пропущен индекс и второй аналирует сколько раз были использованы индексы .. и нет ли лишних индексов в сестеме ..
> понятно, зависит от системы, в идеале незначительно Да, в идеале. Но почему Вы думаете, что конкретный сервер "идеален" (для этого по ссылке и описана утилита для тестирования)? ;) > чем больше маленьких операций, тем больше измерений и больше оверхед Да. Насколько я помню, gettimeofday вызывается дважды для каждого tuple, проходящего через plan node. > - то есть в идеале это все-таки проценты или десятки процентов Если у Вас сплошь seq.scans узких таблиц, где много rows — может быть и куда больше. Вот пример, на первой попавшейся таблице: seq.scan таблицы с pg_column_size = 36, 10000000 rows: COUNT(*): Time: 442,860 ms EXPLAIN (ANALYZE) COUNT(*): Execution Time: 835.380 ms
Обсуждают сегодня