| От | Tom Lane |
|---|---|
| Тема | Re: "explain analyse" much slower than actual query |
| Дата | |
| Msg-id | 22445.1170019695@sss.pgh.pa.us обсуждение |
| Ответ на | Re: "explain analyse" much slower than actual query ("Phil Endecott" <spam_from_postgresql_general@chezphil.org>) |
| Список | pgsql-general |
"Phil Endecott" <spam_from_postgresql_general@chezphil.org> writes:
> If I understand it correctly, it is still doing a sequential scan on
> part_tsearch that does not terminate early due to the limit clause. So
> I'm still seeing run times that are rather worse than I think should be
> possible. Can it not step through the indexes in the way that it does
> for a Merge Join until it has got enough results to satisfy the limit,
> and then terminate?
Nope, there is not that much intelligence about NOT IN.
You could possibly manually rewrite the thing as a LEFT JOIN
with a WHERE inner-join-key IS NULL clause. This would probably
lose if most of the outer relation's rows join to many inner rows,
though.
regards, tom lane
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера