Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs
Date
Msg-id 3A65FC38.3A749B4D@tm.ee
Whole thread Raw
In response to Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs  (bruc@stone.congenomics.com (Robert E. Bruccoleri))
List 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 by date:

Previous
From: ncm@zembu.com (Nathan Myers)
Date:
Subject: Re: copy from stdin; bug?
Next
From: Ian Lance Taylor
Date:
Subject: Cursors in PL/pgSQL