Re: Optimizing a request

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Optimizing a request
Дата
Msg-id 14630.1093983238@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Optimizing a request  (Jean-Max Reymond <jmreymond@gmail.com>)
Ответы Re: Optimizing a request  (Jean-Max Reymond <jmreymond@gmail.com>)
Список pgsql-performance
Jean-Max Reymond <jmreymond@gmail.com> writes:
> explain SELECT art_id, art_titre, art_texte, rub_titre
> FROM article inner join rubrique on article.rub_id = rubrique.rub_id
> where rub_parent = 8;

> Hash Join  (cost=8.27..265637.59 rows=25 width=130)
>   Hash Cond: ("outer".rub_id = "inner".rub_id)
>   ->  Seq Scan on article  (cost=0.00..215629.00 rows=10000000 width=108)
>   ->  Hash  (cost=8.26..8.26 rows=3 width=22)
>         ->  Index Scan using rubrique_parent on rubrique
> (cost=0.00..8.26 rows=3 width=22)
>               Index Cond: (rub_parent = 8)

That seems like a very strange plan choice given those estimated row
counts.  I'd have expected it to use a nestloop with inner index scan
on article_rub_id_index.  You haven't done anything odd like disable
nestloop, have you?

What plan do you get if you turn off enable_hashjoin?  (If it's a merge
join, then turn off enable_mergejoin and try again.)  Also, could we see
EXPLAIN ANALYZE not just EXPLAIN output for all these cases?

            regards, tom lane

В списке pgsql-performance по дате отправления:

Предыдущее
От: Jean-Max Reymond
Дата:
Сообщение: Re: Optimizing a request
Следующее
От: "Gary Doades"
Дата:
Сообщение: Re: Optimizing a request