Skip site navigation (1) Skip section navigation (2)

Re: Optimizing a request

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jean-Max Reymond <jmreymond(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Optimizing a request
Date: 2004-08-31 20:13:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
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

In response to


pgsql-performance by date

Next:From: Gary DoadesDate: 2004-08-31 20:16:46
Subject: Re: Optimizing a request
Previous:From: Jean-Max ReymondDate: 2004-08-31 19:42:56
Subject: Re: Optimizing a request

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group