From: | "Gary Doades" <gpd(at)gpdnet(dot)co(dot)uk> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Optimizing a request |
Date: | 2004-08-31 19:21:49 |
Message-ID: | 4134DDDD.428.4AF67CC@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 31 Aug 2004 at 20:59, Jean-Max Reymond wrote:
> hi,
>
> I want to optimize the following request and avoid the seq scan on the
> table article (10000000 rows).
>
> 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)
>
>
> thanks for your answers,
>
> --
Have you run ANALYZE on this database after creating the indexes or
loading the data?
What percentage of rows in the "article" table are likely to match the
keys selected from the "rubrique" table?
If it is likely to fetch a high proportion of the rows from article then it
may be best that a seq scan is performed.
What are your non-default postgresql.conf settings? It may be better to
increase the default_statistics_target (to say 100 to
200) before running ANALYZE and then re-run the
query.
Cheers,
Gary.
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Max Reymond | 2004-08-31 19:42:56 | Re: Optimizing a request |
Previous Message | Jean-Max Reymond | 2004-08-31 19:19:09 | Re: Optimizing a request |