On 31 Aug 2004 at 21:42, Jean-Max Reymond wrote:
> ----- Original Message -----
> From: Gary Doades <gpd@gpdnet.co.uk>
> Date: Tue, 31 Aug 2004 20:21:49 +0100
> Subject: Re: [PERFORM] Optimizing a request
> To: pgsql-performance@postgresql.org
>
>
>
> > Have you run ANALYZE on this database after creating the indexes or loading the data?
>
> the indexes are created and the data loaded and then, I run vacuum analyze.
>
> >What percentage of rows in the "article" table are likely to match
> the keys selected from the "rubrique" table?
>
> only 1 record.
>
> 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.
>
> yes, default_statistics_target is set to the default_value.
> I have just increased shared_buffers and effective_cache_size to give
> advantage of 1 Mb RAM
>
I can only presume you mean 1 GB RAM. What exactly are your
settings for shared buffers and effective_cache_size?
Can you increase default_statistics_target and re-test? It is possible
that with such a large table that the distribution of values is skewed and
postgres does not realise that an index scan would be better.
It seems very odd otherwise that only on row out of 10,000,000 could
match and postgres does not realise this.
Can you post an explain analyse (not just explain) for this query?
Cheers,
Gary.
