Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: bruc(at)acm(dot)org
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs
Date: 2001-01-17 20:10:32
Message-ID: 3A65FC38.3A749B4D@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ian Lance Taylor 2001-01-17 20:49:00 Cursors in PL/pgSQL
Previous Message Nathan Myers 2001-01-17 19:50:05 Re: copy from stdin; bug?