Re: Optimizing a request

Jean-Max Reymond <jmreymond(at)gmail(dot)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