Приветствую,

есть табличка, на ней индекс по трем полям.



Показывает index_scan, все норм.





Показывает
1) Seq_Scan, т.е. полное сканирование таблицы table1
2) Запрос SELECT id FROM table2 на самом деле сложнее, с несколькими join, так в этом случае везде nested loops, а если отедльно выполнить то hash join.

Временные таблицы создавать нельзя, т.к. реплика.


Как сделать чтобы в условие IN вставились результаты запроса и при этом план не "поехал" ?

УткъТак


Показывает тоже норм- index_scan.

Щукина АннаУткъ,

Во-первых, лучше приводить оригинальный план, а не его вольный краткий пересказ.
Во-вторых, PG в случае с подзапросом не может оценить кардинальность выборки и решает, что скан таблицы выгоднее, чем чтение индекса с последующим доступом к таблице.

Для начала - попробуйте переписать IN-запрос в форму джойна с основной таблицей.

По поводу hash / nested - вполне себе логично. При IN-фильтре оптимизатор придерживается стратегии быстрого получения первых строк результата (отсюда вложенные циклы). При выполнении отдельным стейтментом оптимизатор пытается придерживаться стратегии быстрого получения всего результирующего множества (отсюда хэш-соединения).

В терминах и определениях могу путаться. Более знающие товарищи, надуюсь, подправят... :)


Спасибо за ответ.


Просто в table1 на 4 порядка больше данных чем в table2.


Про IN-фильтр не совсем понял. Сейчас переписал через CTE и план стал использовать индекс, хотя запрос выглядит примерно так:



Почему когда напрямую запрос вставляю в IN - план превращается в кашу?

Maxim BogukУткъ,

Вы бы explain analyze бы показали для обоих случаев.


--
Maxim Boguk
dataegret.ru


К сожалению, нет такой возможности.

Версия постгрес 9.5