Re: Optimizing a request

Поиск
Список
Период
Сортировка
От Gary Doades
Тема Re: Optimizing a request
Дата
Msg-id 4134DDDD.428.4AF67CC@localhost
обсуждение исходный текст
Ответ на Optimizing a request  (Jean-Max Reymond <jmreymond@gmail.com>)
Ответы Re: Optimizing a request  (Jean-Max Reymond <jmreymond@gmail.com>)
Список 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.

В списке pgsql-performance по дате отправления:

Предыдущее
От: Jean-Max Reymond
Дата:
Сообщение: Re: Optimizing a request
Следующее
От: William Yu
Дата:
Сообщение: Re: Table UPDATE is too slow