Re: Optimizing a request

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