Index Scan и Seq Scan возвращают разное количество ожидаемых строчек
Index Scan using ni_child_parent_uuid on child c (cost=0.43..1286.53 rows=636 width=16)(actual time=0.037..0.479 rows=206 loops=1)
Index Cond: (parent_uuid = '752726e3-af63-49a8-93e7-cfda65be27af'::uuid)
Parallel Seq Scan on child c (cost=0.00..831237.98 rows=91 width=16)(actual time=8232.835..11644.969 rows=206 loops=1)
Filter: (parent_uuid = '752726e3-af63-49a8-93e7-cfda65be27af'::uuid)
Почему отличается количество ожидаемых записей? Условие одно, бд одна, все одинаковое, просто в одном используется seq scan, а в другом используется index scan с помощью pg_hint_plan IndexScan(c).
Из-за разницы в 6 раз, в сложном запросе с джоинами оптимизатор предпочитает использовать seq scan, тк уменьшение в 6 раз очень сильно влияет на cost join.
Ответы (1 шт):
Автор решения: Даурен Байманов
→ Ссылка
Потому, что это количество строчек для одного запланированного процесса.
В данном случае запланировано 7 воркеров, 636/7=91.
P.S.: Проблема с запросом была связана, с недостаточной статистикой, увеличил - помогло:
alter table child alter column parent_uuid set statistics 10000