Re: Cannot get to use index scan on a big table!

Поиск
Список
Период
Сортировка
От Stephan Szabo
Тема Re: Cannot get to use index scan on a big table!
Дата
Msg-id 20020423075534.S13153-100000@megazone23.bigpanda.com
обсуждение исходный текст
Ответ на Cannot get to use index scan on a big table!  (Rajesh Kumar Mallah <mallah@trade-india.com>)
Список 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 по дате отправления:

Предыдущее
От: "Ian Cass"
Дата:
Сообщение: Re: Date indexing
Следующее
От: "Ruben Vivas"
Дата:
Сообщение: calling a pl/pgsql function with array in argument