Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs
Дата
Msg-id 3A65FC38.3A749B4D@tm.ee
обсуждение исходный текст
Ответ на Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs  (bruc@stone.congenomics.com (Robert E. Bruccoleri))
Список pgsql-hackers
"Robert E. Bruccoleri" wrote:
> 
> >
> > what are the cost estimates when you run explain with seqscan disabled ?
> > do => SET ENABLE_SEQSCAN TO OFF;
> > see:
> > (http://www.postgresql.org/devel-corner/docs/admin/runtime-config.htm#RUNTIME-CONFIG-OPTIMIZER)
> 
> Here's the result from EXPLAIN:
> 
> Aggregate  (cost=19966.21..19966.21 rows=1 width=0)
>   ->  Index Scan using comparisons_4_code on comparisons_4  (cost=0.00..19947.73 rows=7391 width=0)
> 
> The estimates are too high.

You could try experimenting with 

SET RANDOM_PAGE_COST TO x.x;

from the page above

RANDOM_PAGE_COST (floating point)
      Sets the query optimizer's estimate of the cost of a
nonsequentially fetched disk page.       this is measured as a multiple of the cost of a sequential page
fetch. 
      Note: Unfortunately, there is no well-defined method of
determining ideal values for       the family of "COST" variables that were just described. You are
encouraged to      experiment and share your findings.


-------------
Hannu


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

Предыдущее
От: ncm@zembu.com (Nathan Myers)
Дата:
Сообщение: Re: copy from stdin; bug?
Следующее
От: Ian Lance Taylor
Дата:
Сообщение: Cursors in PL/pgSQL