Re: Index problem

Поиск
Список
Период
Сортировка
От Matt Clark
Тема Re: Index problem
Дата
Msg-id OAEAKHEHCMLBLIDGAFELKEBIDMAA.matt@ymogen.net
обсуждение исходный текст
Ответ на Re: Index problem  ("Rigmor Ukuhe" <rigmor.ukuhe@finestmedia.com>)
Список pgsql-performance
> There are about 2500 rows in that table.
>
> 1st query explain analyze: Seq Scan on PRIORITY_STATISTICS
> (cost=0.00..491.44 rows=127 width=12) (actual time=98.58..98.58 rows=0
> loops=1)
> Total runtime: 98.74 msec
>
> 2nd query explain analyze: NOTICE:  QUERY PLAN:
>
> Index Scan using PRIORITY_STATISTICS_reo_id, PRIORITY_STATISTICS_reo_id,
[snip]
> PRIORITY_STATISTICS_reo_id on PRIORITY_STATISTICS  (cost=0.00..394.06
> rows=102 width=12) (actual time=20.93..20.93 rows=0 loops=1)
> Total runtime: 21.59 msec

With only 2500 rows the planner could be deciding that it's going to have to read every disk block to do an index scan
anyway,so it 
might as well do a sequential scan.  If the pages are in fact in the kernel cache then the compute time will dominate,
notthe IO 
time, so it ends up looking like a bad plan, but it's probably not really such a bad plan...

Is your effective_cache_size set to something sensibly large?

You could also try decreasing cpu_index_tuple_cost and cpu_tuple_cost.  These will affect all your queries though, so
whatyou gain 
on one might be lost on another.

Matt



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

Предыдущее
От: "Rigmor Ukuhe"
Дата:
Сообщение: Re: Index problem
Следующее
От: Palle Girgensohn
Дата:
Сообщение: performance hit when joining with a view?