On 31 Aug 2004 at 21:42, Jean-Max Reymond wrote:

> ----- Original Message -----
> From: Gary Doades <[EMAIL PROTECTED]>
> Date: Tue, 31 Aug 2004 20:21:49 +0100
> Subject: Re: [PERFORM] Optimizing a request
> > 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?


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to