Re: Cannot get to use index scan on a big table! - Mailing list pgsql-sql

From Stephan Szabo
Subject Re: Cannot get to use index scan on a big table!
Date
Msg-id 20020423075534.S13153-100000@megazone23.bigpanda.com
Whole thread Raw
In response to Cannot get to use index scan on a big table!  (Rajesh Kumar Mallah <mallah@trade-india.com>)
List pgsql-sql
On Tue, 23 Apr 2002, Rajesh Kumar Mallah wrote:

> i have a simple SQL query and it does not seems to use index
> despite its existance and VCUUMING of table.
>
> tradein_clients=> explain  select email_id from email_source  where
> source_id=186 ;
> NOTICE:  QUERY PLAN:
>
> Seq Scan on email_source  (cost=0.00..19191.50 rows=41602 width=4)
>
> EXPLAIN
> tradein_clients=>
>
> (can anyone please explain why the figure 41602??)

That's the estimated number of matching rows.  I'd guess that this
number is an over estimate (how many rows actually are returned?)
Do you have any particularly frequent values of source_id that are much
more common than others?  7.1 and earlier had problems with over
estimating the number of matching rows when the distribution had a
very uneven distribution of values, select * from pg_statistic where
starelid=(select oid from pg_class where relname='email_source')
should give the stored statistics from the analyze.

As a comparison, if you do "set enable_seqscan=off;" and then do
the query and explain, what does it give for the costs there, and
does it take less time?



pgsql-sql by date:

Previous
From: "Ian Cass"
Date:
Subject: Re: Date indexing
Next
From: "Ruben Vivas"
Date:
Subject: calling a pl/pgsql function with array in argument