rinaceMaxim Boguk,
тут могут быть проблемы
продакшн
если производительность не измениться гипотеза будет проверена
если производительность ухудшится - будет нехорошо со стороны заказчика
А тестовая база, довольно сильно отличается от продакшн, так,что планы там совсем разные
Индекс на таблицу в 100 строк восстанавливается назад за пару секунд.
Без экспериментов на той конкретной базе где наблюдаются проблемы с планом запроса (или на ее очень близкой копии по данным и оборудованию) - обычно проблему решить не получается.
1) Почему в первом случае loops=24913020
В первом случае у вас nestedloop план а во втором hash join (а они совсем по разному делаются отсюда и разница в loops).
Вообще план в первом случае выглядит странным на мой взгляд.
А что показывает explain analyze для упрощенного запроса вида
SELECT
*
FROM
ALFDCCONTEXT alf
INNER JOIN STRATEGY s ON alf.strategyid = s.strategyid
INNER JOIN EQUIPMENT e ON e.equipmentid = s.equipmentid
WHERE
e.groupname <> 'SAMPLE GROUP'
AND alf.baddcqv = 0
AND e.equipmentname = 'EV14';
?
ps: меня слегка смущает наличие одновременно s.strategyid = als.strategyid И alf.strategyid = s.strategyid в одном условии join в вашем запросе
2) Как построение индекса по маленькой таблице так кардинально изменило план выполнения ?
При отсутствии бага (что неисключено) в планировщике - план неиспользующий индекс не должен менятся от наличия или отсутствия этого индекса (лет 7 назад был милый баг когда это было не так но с тех пор я ничего похожего не встречал).
3) Нет ли проблем с analyze ? Как в этом можно убедится ?
Не видно очевидных ошибок в ожидаемом количестве строк. Значить все более менее ок с статистикой.
Но: вообще таблицы с 1-100 строк любят пропускаться или редко обрабатываться autoanalyze потому что есть такая штука как autovacuum_analyze_threshold который 50 строк по умолчанию (что для маленьких таблиц - легко может быть больше половины).
Иногда полезно перед тем как делать индексы - сделать ручной analyze всем участвующим таблицам.
И в общем если у вас много мелких таблиц и сложные запосы я бо порекомендовал бы уменьшить его до 10 или даже до 2-3.
ps: я бы еще можен на счет join_collapse_limit/from_collapse_limit бы подумал... таблиц у вас много в запросе может не хватать для получения стабильных планов (geqo оптимизатор дело такое... вероятностное в лучшем случае). Какие у вас настройки на этот счет.
pps: 'Но подтвердить или опровергнуть эту гипотезу не имея истории autoanalyze пока нет возможности' - в pg_stat_user_tables есть колонки
1.
2.
3.
4.
5.
6.
7.
last_vacuum | timestamp with time zone | | | | plain |
last_autovacuum | timestamp with time zone | | | | plain |
last_analyze | timestamp with time zone | | | | plain |
last_autoanalyze | timestamp with time zone | | | | plain |
vacuum_count | bigint | | | | plain |
autovacuum_count | bigint | | | | plain |
analyze_count | bigint | | | | plain |
autoanalyze_count | bigint | | | | plain |
которые иногда могут помочь с этим вопросом.
