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

Re: Optimizing a request

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 (view raw or flat)
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.

In response to

Responses

pgsql-performance by date

Next:From: Jean-Max ReymondDate: 2004-08-31 19:42:56
Subject: Re: Optimizing a request
Previous:From: Jean-Max ReymondDate: 2004-08-31 19:19:09
Subject: Re: Optimizing a request

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