Jean-Max Reymond <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
